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Preface 



The International Conference on Mathematical Knowledge Management has now 
reached its third edition, creating and establishing an original and stimulating 
scientific community transversal to many different fields and research topics. The 
broad goal of MKM is the exploration of innovative, semantically enriched, dig- 
ital encodings of mathematical information, and the study of new services and 
tools exploiting the machine-understandable nature of the information. MKM 
is naturally located in the border area between digital libraries and the mecha- 
nization of mathematics, devoting a particular interest to the new developments 
in information technology, and fostering their application to the realm of math- 
ematical information. The conference is meant to be a forum for presenting, 
discussing and comparing new tools and systems, standardization efforts, criti- 
cal surveys, large experiments, and case studies. At present, we are still getting to 
know each other, to understand the work done by other people, and the potential- 
ities offered by their work to our own research activity. However, the conference 
is rapidly acquiring scientific strength and academic interest, attracting more 
and more people and research groups, and offering a challenging alternative to 
older, more conservative conferences. 



July 2004 



Andrea Asperti 
Grzegorz Bancerek 
Andrzej Trybulec 




Organization 



MKM 2004 was organized by the Institute of Computer Science, University of 
Bialystok in co-operation with the Faculty of Computer Science, Bialystok Tech- 
nical University and the Association of Mizar Users. 



Program Committee 



Andrzej Trybulec (Chair) 
Andrew A. Adams 
Andrea Asperti 
Bruno Buchberger 
Roy McCasland 
James Davenport 
William M. Farmer 
Herman Geuvers 
Therese Hardin 
Fairouz Kamareddine 
Michael Kohlhase 
Paul Libbrecht 
Bengt Nordstrom 
Renaud Rioboo 
Bernd Wegner 



University of Bialystok, Poland 

University of Reading, UK 

University of Bologna, Italy 

RISC Linz, Austria 

University of Edinburgh, UK 

University of Bath, UK 

McMaster University, Canada 

Catholic University of Nijmegen, NL 

Pierre & Marie Curie University, France 

Heriot-Watt University, UK 

International University Bremen, Germany 

Saarland University, Germany 

Chalmers University of Technology, Sweden 

Pierre & Marie Curie University, France 

Technical University of Berlin, Germany 



Co-referees 






Grzegorz Bancerek 


Gueorgui Jojgov 


Piotr Rudnicki 


Jacques Carette 


Wolfram Kahl 


Claudio Sacerdoti Coen 


David Carlisle 


Temur Kutsia 


Pierre-Yves Strub 


Luis Cruz-Filipe 


Iris Loeb 


Carsten Ullrich 


Flavio de Moura 


Manuel Maarek 


Freek Wiedijk 


Hazel Duncan 


Lionel Elie Mamane 


Wolfgang Windsteiger 


Lilia Georgieva 


Andreas Meier 


Daniel Winterstein 


George Goguadze 


Immanuel Normann 


Stefano Zacchiroli 


Dimitri Hendriks 


Luca Padovani 


Jurgen Zimmer 


Martin Homik 


Fiorina Piroi 


Claus Zinn 


Klaus Jantke 


Tom Ridge 






Organizing Committee 



Roman Matuszewski (Conference Chair) 

Adam Naumowicz 

Adam Grabowski 

Mariusz Giero 

Magda Polubiec 

Jan Matuszewski 



University of Bialystok, Poland 
University of Bialystok, Poland 
University of Bialystok, Poland 
University of Bialystok, Poland 



Sponsoring Institution 

Centrum Informatyki ZETO s.a., Bialystok, Poland 






Table of Contents 



Copyright Issues for MKM 

Andrew A. Adams, James H. Davenport 1 

Efficient Retrieval of Mathematical Statements 

Andrea Asperti, Matteo Selmi 17 

Formalizing Set Theory as it Is Actually Used 

Arnon Avron 32 

Integrated Semantic Browsing of the Mizar Mathematical Library 
for Authoring Mizar Articles 

Grzegorz Bancerek, Josef Urban 44 

Informalising Formal Mathematics: Searching the Mizar Library 
with Latent Semantics 

Paul Cairns 58 

Mathematical Service Matching Using Description Logic and OWL 

Olga Caprotti, Mike Dewar, Daniele Turi 73 

C-CoRN, the Constructive Coq Repository at Nijmegen 

Lms Cruz-Filipe, Herman Geuvers, Freek Wiedijk 88 

Classifying Differential Equations on the Web 

Dirk Draheim, Winfried Neun, Dima Suliman 104 

Managing Heterogeneous Theories Within a Mathematical Knowledge 
Repository 

Adam Grabowski, Markus Moschner 116 

Rough Concept Analysis - Theory Development in the Mizar System 

Adam Grabowski, Christoph Schwarzweller 130 

A Path to Faithful Formalizations of Mathematics 

Gueorgui Jojgov, Rob Nederpelt 145 

Flexible Encoding of Mathematics on the Computer 

Fairouz Kamareddine, Manuel Maarek, Joe B. Wells 160 

CPoiNT: Dissolving the Author’s Dilemma 

Andrea Kohlhase, Michael Kohlhase 175 

On Diagrammatic Representation of Mathematical Knowledge 

Zenon Kulpa 190 




X 



Table of Contents 



Predicate Logic with Sequence Variables and Sequence Function 
Symbols 

Temur Kutsia, Bruno Buchberger 205 

A Graph-Based Approach Towards Discerning Inherent Structures 
in a Digital Library of Formal Mathematics 

Lori Lorigo, Jon Kleinberg, Richard Eaton, Robert Constable 220 

Theorem Proving and Proof Verification in the System SAD 

Alexander Lyaletski, Andrey Paskevich, Konstantin Verchinine 236 

Adaptive Access to a Proof Planner 

Erica Metis, Andreas Meier, Martin Pallet 251 

Modeling Interactivity for Mathematics Learning by Demonstration 

Miguel A. Mora, Roberto Moriyon, Francisco Saiz 265 

Extraction of Logical Structure from Articles in Mathematics 

Koji Nakagawa, Akihiro Nomura, Masakazu Suzuki 276 

Improving MiZAR Texts with Properties and Requirements 

Adam Naumowicz, Czeslaw Bylihski 290 

An Investigation on the Dynamics of Direct-Manipulation Editors 
for Mathematics 

Luca Padovani, Riccardo Solmi 302 

Intuitive and Formal Representations: The Case of Matrices 

Martin Pallet, Volker Sorge, Manfred Kerber 317 

Mathematical Libraries as Proof Assistant Environments 

Claudio Sacerdoti Coen 332 

Efficient Ambiguous Parsing of Mathematical Formulae 

Claudio Sacerdoti Coen, Stefano Zacchiroli 347 

An Architecture for Distributed Mathematical Web Services 

Elena S. Smirnova, Clare M. So, Stephen M. Watt 363 

The Categorial Type of OpenMath Objects 

Andreas Strotmann 378 



Author Index 



393 




Copyright Issues for MKM 



Andrew A. Adams^ and James H. Davenport^’* 

^ The University of Reading, A . A . AdamsSRdg .ac.uk 
^ The University of Bath, J.H.Davenport@bath.ac.uk 



Abstract. We present an overview of the current situation and recent 
and expected future developments in areas of copyright law and eco- 
nomics relevant to Mathematical Knowledge Management. 



1 Introduction 

The advent of digital information distribution has created both new opportuni- 
ties and new challenges in all information-rich fields. The new field of MKM is 
itself based on this advent. As in all other fields some of the challenges for MKM 
are social and legal as well as technical. As Lessig [4] put forward, social norms, 
law, economics and technology are strongly interdependent spheres. Although 
the primary aims of the MKM community are technical in nature the ramifica- 
tions of technology for these other areas, and the constraints of these other areas 
on what technology is useful, must be addressed by this community. Here, based 
on the reports (Deliverables 1.1 and 1.2) from Project MKMNet, we present 
some social and legal aspects of copyright which are central to the way in which 
MKM technology may develop. There is an enormous debate currently underway 
in society on how to move forward in a digital information age with laws and 
social norms based upon analogue understandings of technological possibilities. 
This debate is addressed below in Section 1.1, although readers interested only 
in the current situation and the practical implications for MKM may wish to 
skip over it. 

1.1 Information Wants to be Free, People Want to be Paid 

The phrase “Information Wants to be Free” has become something of a rallying 
cry for those who object to the restrictive practices of the so-called “copyright 
industries” and their representative trade bodies such as the IFIP (the interna- 
tional trade body representing music recording publishers) . The phrase has some 
unfortunate aspects to it but the essence is that in the digital era it is almost im- 
possible to control the copying and (re)distribution of information even as much 
as was possible in the earlier analogue era. Various variations of the phrase have 
been used to oppose this on philosophical, practical or economic grounds such 
as “if information wants to be free then who’s going to pay for it?” . The version 



* This work was supported by EU Grant MKMNet IST-2001-37057 and UK EPSRC 
Grant GR/S10919. 
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we will consider in this article is that while information, by its nature, can be 
easily copied and redistributed, the people who produce the information and who 
provide value-added services making it more accessible in some way, need to pay 
the bills and so “want to be paid”. In the midst of the industrial revolution 
the so-called “copyright bargain” was therefore struck which granted authors 
a limited monopoly on the exploitation of their creation so as to ensure that 
further acts of creation would be encouraged. Other voices at the time argued 
on both sides of this compromise, one group regarding intellectual creation as an 
inalienable part of the personality of the creator or creators and therefore worthy 
of perpetual protection, the other regarding each act of creation as building on 
prior creations ( “If I have seen further it is by standing upon the shoulders of 
giants.” Sir Isaac Newton; “there is no new thing under the sun” Ecclesiastes 1:9 
King James version) and therefore allowing no basis for monopolistic protection. 

The growth of the internet in terms of number of users, speed of access and 
types or amount of content has upset the copyright bargain’s basic premise which 
is that the act of making a copy can be simply subjected to restrictions in order 
to make information (relatively) freely available while ensuring that creators 
are paid. The particular academic ramification of this problem comes with the 
structures that have built up around academic publishing of material. These 
structures may well have been reasonable as they were incrementally produced 
but a number of changes have placed as great a strain on them as has been seen 
in the music recording publishing business. Various solutions are being proposed 
to the problems of the current system, which we shall present in Section 6. 

1.2 Guide to the Paper 

Mathematics is an international field of study and the internet makes border- 
less access to information more feasible, although natural language and semantic 
differences between country or regional groupings provide technical challenges 
to MKM. Both the legal basis of copyright ownership of creative work (which 
includes mathematics) and the social norms/working practices in both academic 
and non-academic settings in various places provide challenges for international 
MKM efforts. In Section 2 we present a limited survey of the original ownership 
question for (principally) mathematical papers (other areas of mathematical 
knowledge, such as teaching material and computer programs are sometimes 
dealt with where differences are known). Once it is clear who owns the original 
copyright we must consider what happens to copyright when the work is pub- 
lished. This is usually achieved through peer-reviewed journals for mathematical 
papers and so in Section 3 we present information about the current practice of 
various publishers and owners (as is made clear in Section 2 the original author 
is not necessarily the initial owner) when arranging for publication. In addi- 
tion to the mathematical information itself MKM is also highly concerned with 
metadata such as databases of citations, publication information, and extracts 
(such as abstracts) concerned with mathematical publishing. In Section 4 there- 
fore we consider ownership rights and economic aspects for metadata, including 
an overview of ownership rights for databases. Having covered the ownership 
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question we then turn our attention to the general situation of digital rights 
management (DRM) seen by some as the technological solution to a technolog- 
ical problem in Section 5. We then cover the issue of current and future journal 
publication in terms of economics, legal issues, author rights and technology in 
Section 6, including a brief analysis of access to older material. 



2 Original Ownership of Copyright 

The question of who has the copyright in an original piece of unpublished math- 
ematics is interesting. For the vast majority of authors (Ph.D. students, hobby- 
ists and retired academics apart), it could be argued that producing publishable 
mathematics is part of their job, and therefore, in the phrase used in English 
law, it is a “work made for hire”, and so the employer might claim to own it. 
The situation in practice is more complicated, and the following examples were 
obtained. 

U.S. Federal Government: Claims the rights to all material produced by em- 
ployees during their normal work and does not allow for the transfer of 
ownership to third parties. This has specific ramifications for publication in 
journals (see Section 3). 

British Universities tend to have clauses in their employment contracts that 
says that they do not claim this sort of copyright, though increasingly (e.g. 
in 1998 at Bath) they are adding clauses that say that, nonetheless, they 
have a licence to use it. This is required by the increasing regulation of 
British Universities, which may require such material to be submitted for 
the purposes of the Research Assessment Exercise (see www.hefce.ac.uk) 
or other exercises. 

Technological developments in teaching software has produced a new con- 
cept, that of the Virtual Managed Learning Environment (VMLE). The mod- 
ularisation of Higher Education in the UK, and the pressure on Universities 
to develop new sources of funding (both direct pressure from government and 
HEFCE and indirect pressure due to underfunding) have led to Universities 
viewing the contents (not the structural software which is generally off-the- 
shelf externally-owned or internally developed) of such VMLEs as University 
Intellectual Property which might be exploited for monetary gain or traded 
with other providers to offset production costs in other topics. However, 
existing academic contracts are mostly either unclear on such matters or 
leave copyright ownership with the academic(s) who produce such the con- 
tent. Most Universities are reviewing their regulations (as mentioned above) 
and this is often one of the contentious issues between Universities and staff 
representatives (often the AUT and/or NATFHE). 

However, most UK academics explicitly retain all rights in their scholarly 
work including the right to transfer it if required/desirable. The nebulous 
nature of the working day for British Academics make this an unclear area of 
law. Since academics generally have not signed waivers under the European 
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Working Time Directive^ and many frequently work more than a forty eight 
hour week on a regular basis, any claim by the University to a specific piece 
of intellectual property the production of which was not absolutely mandated 
by their contract and specifically requested by their manager would be very 
difficult to enforce. 

German Universities seem, from discussion at MKM ’03, not to make such 
things explicit, but the assumption made by academics was that they had 
the copyright. A similar situation seems to pertain in Italy and France. The 
copyright law of these countries is quite divergent from that of the UK/US, 
in particular in the concept of “moral rights” which extend much further 
than required in international copyright treaties (and indeed are the source 
for Moral Rights existing in those treaties at all). Full transfer of copyright 
is not possible under these laws, only the assignment of exclusive rights to 
publish/exploit the work, and the concept of “work-for-hire” is missing or 
very weak in these jurisdictions. In the past, where publication, copying and 
sale of copyright material were solely physical activities located in an iden- 
tifiable legal jurisdiction this was not problematic. Modern communications 
and electronic print media make this a highly contentious area of IP law 
generally. 

CWI as a Netherlands-funded research institute, does claim the copyright. 
NAG as a private British company does claim the copyright, and makes case- 
by-case decisions on whether to transfer it. 

If the copyright is owned by the author or institution, then it is possible 
for the author or institution to publish the material on internal or external 
web sites^, or submit to pre-print archives such that the Cornell (formerly Los 
Alamos) archive (www.arXiv.org). However, as the work moves towards publi- 
cation, publishers may well require that the work be pulled from external web 
sites. There are persistent rumours, though we have been unable to substantiate 
it, that some Physics journals have refused papers since they are also available 
on the Cornell archive, which does not allow deletion. 

3 Copyright in Published Material 

The practice in the past has been for publishers, academic or commercial, to 
request (often demand) that the copyright in a piece of mathematics to be pub- 
lished^ be transferred to them. The excuse often given is that it makes it easier 
for them to defend the author’s rights. No-one in the network, or others we have 
consulted, could think of an example of this happening with articles or confer- 



^ Council Directive 93/104/EC, 23 November 1993. 

^ A recent classic experience was the August 2002 publication on an Indian web site 
of the “PRIMES is in P” paper, which went round the community within weeks, 
and received more rapid positive comment than a journal editor could ever hope to 
collect in the way of referees’ comments. 

® Book, article, conference proceedings etc. 
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ence proceedings, and the split of royalties on translations of books (which the 
publisher generally does negotiate) is often very unfavourable to the original 
author: typically 50:50 between author and publisher. 

However, there are numerous exceptions to this principle. One important case 
is that U.S. (federal) Government employees are forbidden to transfer copyright, 
and publishers that often deal with these authors tend to have a standard clause 
in the copyright transfer form. At MKM ’03, it was said that several European 
countries do not allow copyright transfer in the same sense at British and Amer- 
ican law does. There is also the interesting question as to which law does apply 
if, say, a French Professor publishes in a journal produced by the American 
subsidiary of a Dutch company (an actual example). It was noted that many 
copyright transfer forms^ are not very specific on the subject. 

Publishers are not always very consistent on this subject either. As one exam- 
ple, the London Mathematical Society asks for copyright transfer for its paper 
journals (even though all these have an electronic parallel edition), but not for 
its all-electronic Journal of Computation and Mathematics. Furthermore, the 
spate of take-overs in the publishing industry has complicated matters. We give 
two examples. 

— The take-over of Academic Press by Elsevier meant that, at least in 2002, 
there were two different sets of procedures, depending on the original history 
of the journal. 

— The transfer of Compositio Mathematica from Kluwer to the London Math- 
ematical Society, means that, in this particular case, authors are asker to 
transfer their copyright to the Compositio Mathematica Foundation. 

Over the past few years, the International Mathematical Union has been pro- 
ducing guidance, suggesting that publishers (at least of articles) should not be 
asking for copyright transfer, and authors should not be ceding the copyright. 
As a result, some publishers (e.g. the American and London Mathematical So- 
cieties), now recommend (rather than demand) such a transfer. At MKM ’03, 
several people reported that, even for publishers that did not offer such an op- 
tion, it had often been possible to negotiate it. 



3.1 Why Authors Might Want to Keep Copyright 

Other than philosophical reasons^ there are several practical reasons. 

1. One may want to publish it on an internal web sites, e.g. for one’s research 
students, and maybe classes. 



^ Which are generally quite brief, normally one side of A4 to avoid intimidating the 
authors. 

® Which can be quite strong. It is often said that academics are the most stupid people 
in the world: they create something at great expense; give it away free to publishers; 
help, generally free of charge, with the refereeing and editing process; and then they 
and their libraries pay vast sums to buy the journals back. 
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2. One may want to publish it on an external website. There is then an issue 
of which version of a paper an author can self-publish: 

The author’s original version (e.g. with article . els); 

The publisher’s version, which may well incorporate formatting that is 
copyright for the publisher. It is quite common for a publisher’s “internal” 
class hie to be more sophisticated than the one issued to authors. 

In either case, there is data mining that can be done with the I^T^X 
source, but not with, say, PDF or Postscript. But the publication of the 
would imply the publication of the class hie, which might prevent the 
previous option. Some authors feel that publishing the DT[;]X might make 
plagiarism easier, but an advanced MKM system should make plagiarism 
much easier to detect. 

It was noted that LMS Journal of Computation and Mathematics pub- 
lishes the PDF, but keeps the DT^X, and has the right to re-generate a new 
format if PDF ceases to be the only useful publishing format. One should 
also note that Springer Lecture Notes in Computer Science allows articles in 
conference proceedings to appear on an external web site. 

3. One may wish to re-use more of the paper, e.g. in a text book, than the 
Berne convention “fair dealing 10%” would permit. Even if the publisher 
ultimately allows this, it still places an administrative burden on the author, 
and publishers have been known to demand royalties if the author neglected 
to get permission. 

Indeed, in publishing a text book, most publishers will require indemnity 
by the author for any unacknowledged use of copyrighted material held by 
another. Reproducing highly similar material from one’s own prior work 
without realising it is not impossible, particularly when trying to explain 
common concepts in one’s research. 



3.2 Publicly Accessible Information on Copyright Policies 

Even though, as mentioned above, publishers are sometimes willing to accept or 
negotiate rights other than a full transfer, most authors are not aware of this. 
The pressure to publish placed by institutions on, particularly junior, academics 
may force them to accept conditions to which they object but to which they do 
not realise they may not be required to submit. 

Even where required copyright assignment is no longer the official policy of 
a publishing organisation (such as the LMS), it may well be some time before 
their public information about publishing policies is updated. This is particularly 
true where commercial publishers (such as Cambridge University Press) are the 
physical publisher of a journal under the auspices of a learned society (as is 
the case for the Bulletin and Journal of the London Mathematical Society and 
the Journal of the Institute of Mathematics of Jussieu, all three of which are 
published by Cambridge University Press). 

A brief investigation into the publicly published policies on copyright for 
journal articles produced the following results: 
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AMS: The American Mathematical Society. The AMS specifically states 
that they only require “Consent to Publish” (i.e. a non-exclusive right to 
print and otherwise distribute the material) . However “an author is encour- 
aged also to transfer copyright of the work to the AMS. In doing so, the 
author retains the right to use the work for his or her own purposes but sim- 
plifies for others the permissions process by enabling the AMS to administer 
it.”® The wording of the AMS statement shows a lack of attention to the 
detail of copyright law. Assigning copyright to the AMS is not needed for 
them to administer rights negotiations and permissions to reprint, a simple 
assignment of those rights to the AMS would do that. What assignment of 
copyright does do is allow the AMS to pursue anyone violating those rights, 
and prevents^ the author from negotiating payment for use of their work. 
There is no mention in the agreement of any sharing of payment that the 
AMS might negotiate/receive for such permissions. 

Oxford University Press. As well as publishing a number of mathematic 
journals of its own, the Oxford University Press publishes on behalf of two 
external sources in Mathematics; The Institute of Mathematics and its Ap- 
plications (IMA) and the Interest Group in Pure and Applied Logics (IGPL) . 
The IMA Journals and the OUP’s own journals require a transfer of copy- 
right to the OUP (not the IMA): “It is a condition of publication in the Jour- 
nal that authors assign copyright to Oxford University Press. This ensures 
that requests from third parties to reproduce articles are handled efficiently 
and consistently and will also allow the article to be as widely disseminated 
as possible. In assigning copyright, authors may use their own material in 
publications provided that the Journal is acknowledged as the original place 
of publication, and Oxford University Press is notified in writing and in 
advance.” 

The Journal of the IGLP situation is somewhat different. The stated pur- 
pose of this journal is to provide a fast and efficient journal publication route 
for a subject where timely reporting of a diverse and growing field is needed. 
As such, the IGPL is published online and full text articles are available for 
free download. There is no explicit notification on the “author submission” 
pages on copyright issues, but the statement regarding “Publication Policy” 
which includes: “We do not mind if a paper which has already been published 
in the Journal is submitted to another journal. It is the author’s responsi- 
bility to inform the new publisher that the paper has already appeared in 
the Journal and that it will be further electronically accessible.” (Emphasis 
in original.) seems to indicate that only the required permission to publish 
and maintain (presumably perpetually) the original paper are required. The 
information for authors on the Journal of Logic and Gomputation website 
gives no information either. The third journal of the IGPL, Journal of Lan- 
guage and Gomputation is reported to have recently switched to Kluwer 



° AMS “Consent to Publish and Copyright Agreement Forms”. 

As specified in the full text of the agreement rather than the above which was taken 
from the explanatory notes about the agreement. 
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Academic Publishers but does not yet appear on their list of journals, so no 
information is available online. 

Kluwer. Kluwer Academic Press require transfer of copyright. Their reasoning 
for this is explained in their September 2003 copyright policy document, 
available on request from their legal department. This would appear to be 
supposedly a non-negotiable standard both for societies using Kluwer as their 
publishing partner and for individual authors. That is the impression given 
by representatives of Kluwer’s legal department, although individual au- 
thors or co-publishers may have found this not to be so strict. As mentioned 
above publishers are sometimes reluctant to acknowledge variations in prac- 
tice to avoid a flood of non-standard requests. “Important elements of the 
publisher’s role in the scientific communication process are peer-reviewing, 
registration and quality assurance. In order to guarantee that the require- 
ments of these three elements are fully met, control of the dissemination of 
the final article is necessary. Permitting an article to be published elsewhere 
on public servers without a clear connection to the peer-reviewed final arti- 
cle can potentially confuse readers who use the article for their own research 
and will not be in the interest of science. By asking for the transfer of copy- 
right from the author to the publisher, Kluwer tries to protect the mutual 
interests of both the author/researcher and the publisher.” 

Elsevier. Elsevier have almost identical requirements for a transfer of copyright 
to Kluwer’s. Their justification is quite interesting: “Elsevier wants to ensure 
that it has the exclusive distribution right, for all media. Such a right can 
be obtained through an exclusive license from authors, but there is virtually 
no difference between transfer and exclusive license. Given that there is vir- 
tually no difference, it seems to us that transfer does give an advantage in 
the elimination of any ambiguity or uncertainty about Elsevier’s ability to 
distribute or sub-license.” 

In particular, the right to distribute is a separate aspect of copyright to 
the right to produce derivative works. Now, while it is highly unusual (though 
not completely unknown) for works of mathematics to be re-interpreted and 
adapted in another medium (which is a different process than simply trans- 
ferring a printed article into a textual article online) the transfer of copyright 
would technically require permission from Elsevier whereas explicit rights to 
publish the article in all media for Elsevier would not include such rights. 
While it is unlikely that Elsevier in its current form would exert such rights, 
it is not entirely outside the bounds of possibility that such a case could arise 
in the future and so the current situation expects that Elsevier (and similar 
publishers) would always maintain their current stance on the issue. Else- 
vier does make a gesture in the direction of derivative works where authors 
retain: “The right to publish a different or extended version of the paper so 
long as it is sufficiently new to be considered a new work.” 

What the difference is between a “derivative work” and a “new work” is 
an interesting question, but too large for this report and so left as an exercise 
for the courts (see literary examples such as “The Wind Done Gone” and 
“Peter Pan: After the Rain” cases in the US and Ganada). 
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Whether academic publishers honestly believe that transfer of copyright is 
beneficial to the academic endeavour, and whether or not they are right in this, is 
not the point of this report. It is clear that many if not most academic publishers 
have received a transfer of copyright for the material they have published in 
journals and sometimes in books, and that they continue to solicit such a transfer, 
either as a pre-requisite before publication or as a strongly supported suggestion 
for authors. The fact that a few major publishing houses hold such copyright 
could be of great benefit to making mathematics freely® available online in that 
only a small number of agreements with publishers would have to be reached to 
include a large portion of existing mathematics in an endeavour. It might also 
present a great obstacle should those companies regard these copyrights as part 
of their assets which they will seek to protect and from which they will seek to 
make further profit. 



4 Copyright in Metadata 

4.1 A Priori Metadata 

This falls into several categories. 

— Unstructured metadata added by the author, such as title, author and, gen- 
erally, abstract. 

~ Unstructured metadata added by the publisher, such as journal, volume, 
page numbers, web addresses for on-line versions (which will generally be 
subscription-based with today’s technology). 

— More rarely, the above two classes could be combined, generally by the pub- 
lisher, into more structured metadata, generally using the “Dublin Core” 
metadata standard. This would form an important part of any Mathemati- 
cal Knowledge Management system, since the unstructured metadata in the 
first two classes varies widely between publishers, and in the absence of a 
uniform approach, one would need to build a case-by-case analysis into any 
metadata search engine, which would be tedious and error-prone. 

If the author has not retained copyright in the paper, then it is fairly clear that 
the copyright in the metadata belongs with the publisher, though it is clearly 
in the publisher’s commercial interest to make the metadata widely available 
to search engines. This is especially important if the publisher makes the on- 
line version of the journal (or other item) available in a binary form such as 
Postscript and PDF, without added external metadata where search engines, 
even if they had access, would not be able to harvest useful information. Where 
authors retain copyright it seems obvious that they grant publishers the right to 
use metadata along with the material. 



“Free as in speech” and/or “free as in beer” to quote Richard Stallman and the Free 
Software Foundation. 
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4.2 A Posteriori Metadata 

The classic examples of this in the mathematical community are the Mathe- 
matical Reviews, Zentralhlatt fiir Mathematik, or possibly Computing Reviews, 
reviews of the paper. The review is generally written by an individual, who may 
or may not be entitled to transfer the copyright to the reviewing organisation (see 
the debate in the previous section) . Clearly, the review would be of no use unless 
the reviewing organisation had at least a licence to use the review. For the copy- 
right in the database created by the reviewing organisation, see the next section. 

4.3 Copyright in Databases 

Few things are less certain in intellectual property rights law that the question 
of whether there is such a thing as “copyright in a database” , as opposed to the 
items in a database. There is currently no international consensus, and cases 
are still fighting their way through the U.S. legal system and legislature. The 
EU does have a sui generis database right, separate from the copyright in the 
individual records, based on the work done in compiling and indexing such a 
database. “A “database” is defined by reg. 6 of the Regulations as a collection of 
independent works, data or other materials which are arranged in a systematic 
or methodical way, and are individually accessible by electronic or other means. 
Database right can subsist in a database regardless of whether copyright also 
subsists. Unlike the law of confidence, there is no requirement that the database 
or its contents should have any commercial or other value.®” 

There have been few cases attempting to enforce this right so far and so the 
actual implementation remains something of a grey area. 

4.4 Bibliographic Databases 

Some of these are the reviewing databases, as described in the previous subsec- 
tion. The on-line versions of these databases are very largely a mathematician’s 
first source of information. Another one of great use is the “Web Of Science”, 
produced by ISL This can be used to find all papers that cite a given paper, thus 
enabling one to chase progress since a particular article. It would be a disaster 
for mathematics, undoing many of the advantages that information technology 
has brought to mathematics, if the absence of any protection for databases led 
these services, or the on-line version of these services, to disappear. On the other 
hand if the use of such services is priced out of reach of too many researchers 
due to over strong protection then this too would be disastrous. 

The other category of bibliographic databases are those maintained, generally 
by individuals and their friends, of publications in a given area. One example is 
the “Harmonic Maps Bibliography” which can be found at www. maths .bath .ac.uk. 
Again, these bibliographic databases, generally accessible over the Internet, are 
a great asset to mathematicians trying to cope with the explosion in the math- 
ematical literature, often said to be doubling every ten years [3]. 



Quoted from the Kingsgate Chambers guide to IP Law: www.nipclaw.com/datab/. 
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4.5 Factual Databases 

Many mathematical software packages are equipped with large databases of 
mathematical facts, which the software can search and/or use. An example of 
these is the database of all finite groups of order <31 contained in the Group 
Theory software GAP. Again, these databases are often compiled by a team on 
the basis of several wider contributions. Things are complicated in this case by 
the fact that GAP is released under an “open source” licence. 

5 Digital Rights Management 

Digital Rights Management technology was seen, in 2001, by many, especially in 
the music and video industries, who claimed to be suffering greatly from Internet 
“piracy” to be the panacea for their woes.^° It was felt at the time of writing 
the MKM proposal that mathematics could just latch on to what were clearly 
going to be industry-standard solutions. However, a more balanced view has now 
emerged, and a recent report [6] has the following in its Executive Summary. 

A principal consequence of deploying DRM technologies is to reduce the 
variety of tools available for accessing and modifying information goods. 
Thus, technological solutions threaten to worsen the imbalance between 
producer and user interests further. 

While there were a plethora of statements about DRM on the W3G website 
in 2000-1, the very few later statements were significantly more pessimistic. In 
2002, we read the following [5]. 

Today, choosing a Digital Rights Management System (DRM) often locks 
you into a limited usage space for the content protected by the DRM 
due to limitations of the client software that plays back the content. To 
give customers what they want and allow broader usage, publishers and 
e-tailers have to offer the content in multiple formats, protected by mul- 
tiple DRM systems. With the lack of a standard business rule definition 
language, these publishers or e-tailers have to specify the business rules 
separately for each DRM system they support. 

As far as one can tell, this was never followed up technically, though W3G 
did issue the following comment^^. 

New technologies are needed to address a variety of issues around copy- 
right and the Web. Electronic copies of a digital (intangible) item have 
no age: one can’t distinguish between the original and the copy. The cost 
of copying has disappeared, which changes the whole landscape for the 
content industry. DRM and metadata can provide the necessary frame- 
work for a new balance and peace in the content arena. 



Often simply described as ‘Napster’. 

^ http : / /www . w3 . org/Submission/2002/05/Coimnent .html. 
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Consequently, this submission is a valuable attempt to provide input 
for a future DRM- Activity. 

There are many Activities around DRM in different Standards bod- 
ies and Consortia around the world. MPEG is integrating DRM into 
MPEG-4, MPEG-7 and MPEG-21, CEN/ISSS has a Steering Group 
around DRM. OASIS just opened a Technical Committee on DRM to 
create a rights-language and Content-guard provided XrML as a contri- 
bution. None of the above mentioned initiatives federate all the stake- 
holders and interested parties around one table. The library community, 
new initiatives like the Creative Commons, like Project Gutenberg or 
consumer-protection associations offer welcome user perspectives too of- 
ten missing from the technical design discussions of rights management 
systems. During the DRM- Workshop stakeholders asked W3C to help 
coordinate this broad variety of initiatives. This was partly done with 
the Workshop and the www-drm mailing-list. 

DRM technologies are broadly covered by patents. This might af- 
fect the widespread use of such technology outside the very commercial 
sectors of the Web. 

The last sentence probably implies that it is W3C’s view that DRM would 
not be applicable for the bulk of mathematics. 

Similarly, there are some proposals in MPEG-21 [1], which state that they 
have some connection with Digital Rights Management, but again follow-up 
seems to be limited, and probably not applicable to our community. The Rights 
Expression Language standard in MPEG-21 was approved by ISO in 2004 [2]. 

A further problem with the DRM technologies advocated by the music and 
video industries in that they tend to block all copying, whereas our commu- 
nity is used to “fair dealing” , and indeed this is currently enshrined in most 
(paper-oriented^^) copyright law. This discrepancy is brought out in the follow- 
ing quotation. 

More specifically, the content development industry, which consists of the 
recording industry and the movie studios, has repeatedly emphasised the 
need for immediate DRM solutions that stop all unauthorised copying 
and distribution. Meanwhile, the information technology industry is em- 
phasising that DRM solutions should support the concept of “fair use”, 
which allows consumers to make copies of some types of copyrighted 
content for their own personal use. In the US, these disagreements have 
led to an increase in both DRM-related lawsuits and new legislative ini- 
tiatives. 



See http://www.eff . org/IP/DRM/20030916/brownback/ statement.pdf for illustra- 
tions of how current interpretations in the U.S. of the DMCA are restricting this, 
http : //www. content- wire . com/drm/drm. cfm?ccs=104fecs=2639. 
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5.1 Is PSP any Better? 

A more recent initiative, the PSP project, describes itself as follows^^. 

The Platform for Privacy Preferences Project (PSP), developed by the 
World Wide Web Consortium, is emerging as an industry standard pro- 
viding a simple, automated way for users to gain more control over the 
use of personal information on Web sites they visit. At its most basic 
level, PSP is a standardised set of multiple-choice questions, covering all 
the major aspects of a Web site’s privacy policies. 

It was originally hoped that this would also deal with issues such as copyright 
information as well as strictly privacy information. However, after the PSP 2.0 
Workshop, the following statement appeared in the minutes^®. 

In general there was no consensus on the exact way how DRM techniques 
and privacy policy enforcement techniques in an enterprise should or 
could relate and this seems to be an interesting open question. 

5.2 The State of Digital Rights Management 

Steinmueller in [6] is pessimistic in his analysis of the future of intellectual prop- 
erty protection (IPP). 

The most likely scenario for future developments will be a set of contin- 
uing skirmishes between those having the greatest interests in enforcing 
IPP rules and those with the greatest interests in defeating IPP. Some 
of the vast numbers of producers and users that are in the middle of 
this battlefield are likely to be caught in the crossfire. They will step 
into various traps designed to capture those viewed as “pirates” by IPP 
proponents or fall victim to the opportunistic behaviour of a growing 
population of “claimants” who have varying degrees of legitimacy. The 
possibility that users will en masse be converted to a regime involving 
strong self-regulation of IPP transgressing behaviours is not considered 
seriously here. While such a regime might be conceivable in some limited 
domain such as the exchange of pirated copies of current hit recordings, 
it simply does not reflect the realities of information use that have been 
considered here. 



5.3 The Current Use of DRM for Academic Papers 

A number of the major publishers have begun making some or all of their publi- 
cations available online. Few of these have made significant efforts to put material 
older than about 1990 online and many of them are only including new material. 
We will discuss the business models of these archives below, but will cover the 
issue of digital rights management for such material here. 



^ http : / /www . w3 . org/P3P/ #what . 
http : / /www . w3 . org/2003/p3p-ws/minutes .html. 
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Most academic papers in mathematical sciences are typeset principally by 
the author using either a wordprocessor or the 1AT[;]X (or T[?;X) systems. Where 
electronic versions are offered by the publisher these are frequently in portable 
document format (PDF) and sometimes in postscript, both of which are easily 
generated from all these input formats. Postscript does not offer much in the way 
of rights management, except that it can be difficult to select and copy portions 
of the text into an editing program, depending on the display tool used. One of 
the motivations for Adobe to produce the PDF specification was to allow the 
inclusion of some digital rights management controls in viewing and production 
software. It is therefore possible to place some restrictions on usage of a PDF file. 
In particular files may require separate passwords for opening or editing a PDF 
file and files may be marked as non-printable. Such restrictions are enforced by 
encrypting the content of the file and allowing only certain viewers to access the 
contents in certain ways (such as not allowing clipboard selection of the viewing 
screen as text and not allowing printer output. As with most DRM facilities these 
only discourage casual and non-technical users from violating the conditions of 
the files since there are always ways around such restrictions: if the material can 
be displayed on screen then it can always be printed via a screen shot at worst. 



6 New Models 

Academic publishing has been showing a great deal of strain in recent years. The 
old model of small publishing houses dedicated to publishing academic journals 
and monographs and making small profits on turnover has been superseded by 
two factors: publishing houses have been merged or taken over by large mul- 
timedia publishing organisations or, where they are attached to a University 
the parent organisation is more interested in the financial returns rather than 
in providing a non-loss-making service to academia at large. Scholarly societies 
who used to generate a significant proportion of their income from publishing ac- 
tivities are finding that the squeeze on University library budgets (caused from 
both ends as real-terms budgets are reduced and as prices from commercial 
publishers increase well beyond inflation) is causing a knock-on effect on their 
subscription income. When the number of institutions subscribing reduces, the 
cost per subscription must rise if “surplus” income for non-profit organisations 
is to be maintained. As these subscription rates increase many academics have 
looked at this model and decided that it is not the right way forward for the 
long term. Since many of the prestigious titles in which to publish are owned 
by the publishing houses new ventures are being brought forward with differ- 
ent models in the hope that they will eventually gain sufficient prestige (via 
their editorial boards, scholarly society affiliations and authors published) to 
supplant the expensive old-style journals. The two main models for this are the 
Open- Access journals and the subsidised journals. In the open access model the 
costs of editing and distribution (primarily maintaining web sites and printing 
bond copies on demand) are paid by authors. In order to avoid authors without 
significant funding from being barred from publishing most such journals op- 
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erate an honour-based system where submitters are trusted to pay unless they 
really do not have funding available. In the subsidised model scholarly societies 
absorb most of the costs of providing fere electronic access (such as the London 
Mathematical Society does for its Journal of Mathematics and Computation) 
by subsidy from other activities including reasonably priced sale of hardbound 
copies to libraries. Existing publishers are also changing their practices some- 
what, including offering tied-deals for access to the full archive of a journal while 
a current subscription exists and even bundling access to a wide-ranging set of 
archives in a single deal or together with a minimum-cost set of print journals 
subscribed to. Given the ownership of much of the existing material in papers 
and monographs (transferred to publishers by trusting academics over the years) 
it is clear that older material will always have a profit-inclusive charge attached 
to it. Whether profit- or surplus-generating publication of academic work can be 
maintained in a connected world where Google replaces the librarian for most 
people is still to be seen. What is certain is that knowledge management in any 
field cannot ignore the economics and legal aspects of ownership of creative work. 



7 Conclusions 

It is clear that appropriate use (and where necessary amendment) of both copy- 
right law and custom and practice in publishing will be a major ideological 
battleground for the twenty first century. This as much if not more true for 
mathematical knowledge as it is for music, films, games and general textual ma- 
terial. Already online sources of information such as the arXive and free or “pay 
to publish” (rather than the prior “pay to purchase”) journals are making in- 
roads against traditional academic publishing models. Free software and open 
source software models are becoming economically viable beyond academic and 
pure research institutions, and are beginning to challenge proprietary software 
producers for market share. 

Because of its very rich level of content (one page of mathematics can contain 
more hours of work, more insight and more useful results than a single page on 
almost other topic) and the broad applicability of mathematical information, a 
share and share alike attitude to mathematical knowledge has always been more 
prevalent than a pay-per-use approach, it is much more clear to both pure and 
applied mathematicians that their “seeing further” has been enabled by “stand- 
ing on the shoulders of giants” (to quote Isaac Newton). As with other areas 
commercial publishers have gained a manner of monopoly on some of the out- 
put of mathematicians. However, unlike the music publishing world, the majority 
of the users are also the producers and the quality controllers of mathematical 
information. Thus the logic of using new technology to its utmost to aid in the 
creation and dissemination of knowledge as freely as possible seems unassailable 
and the biggest problems facing users today is how to ensure continued support 
for each other’s work and not how to continue to support rich pickings for the 
middlemen. 
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In academia, it is well known that one must “publish or perish” and at the 
beginning of an academic career the question of whether to sign over copyright 
to a well-respected journal published by a commercial publisher in order to allow 
publication is not a quandary easily solved. Indeed the copyright to this very 
article has been signed over to Springer- Verlag to enable publication in the LNCS 
series. It is therefore the responsibility of more senior, usually tenured, academic 
staff to promote open access journals and open source or free software so that 
they become the standard routes to academic dissemination. They can do this by 
joining editorial boards of such journals (and resigning from those operated as 
profit-engines for commercial publishers) by publishing their own work in such 
places, and by dedicating as much respect in tenure and promotion decisions to 
such journals as to more established commercial titles. Pressure from University 
administrators to “exploit” mathematical “intellectual property” should not be 
allowed to undermine the fact that the prime purpose of academic endeavour is 
the production of new knowledge, and that this is better achieved both in general 
and in specific by exploiting new communications technologies to their fullest 
potential instead of closing off knowledge in a “pay-to-play” world. In the end 
the vast majority of academic institutions will end up paying more than they 
earn and most of the “earnings” will be spent on legal bills and administration, 
diluting still further the application of resources to the academic goal. 

Mathematicians working in commercial sectors generally understand that 
they provide a service for the rest of their organisation, which are the profit- 
making parts. Even those working in the production of proprietary mathematical 
software often find it more beneficial to publish some of their work freely rather 
than keep it concealed. The emerging benefits of free and open source software 
development methods can provide suitable models. Those publishing material 
in academic publications should realise that they are already giving their work 
away for free and that ensuring as wide an audience as possible will bring far 
more benefits than giving it away to expensive-to-access routes. 
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Abstract. The paper describes an innovative technique for efficient re- 
trieval of mathematical statements from large repositories, developing 
and substantially improving the metadata-based approach introduced 
in [10]. 



1 Introduction 

The increasing amount of mathematical literature published on the web in struc- 
tured, semantically rich XML-formats [16, 13, 15] and the recent combination of 
these technologies with tools for automated deduction and mechanization of for- 
mal reasoning, independently pursued by several European Projects like Open- 
Math, Calculemus, MKM-NET, MoWGLI and Monet has recently renewed the 
interest for efficient indexing and retrieving techniques of single mathematical 
items like theorems, definitions, examples, and so on (see e.g. [11,2,6, 9, 10]). 

Typical techniques to query libraries of structured mathematics are based 
on some kind of (first order) matching, spanning from simple pattern-matching 
techniques to unification to more sophisticated queries comprising e.g. type iso- 
morphisms [5,4]. However, as already pointed out in [10], the straightforward 
iteration of the matching operation over the whole repository of mathematical 
knowledge has serious scalability problems with respect to the dimension of the 
library. For instance, the MBase system [12], thanks to a clever implementa- 
tion of unification, is able to iterate matching on a data base of 6000 theorems 
(that is, a pretty small library) in about 1 second: if this performance is possi- 
bly acceptable for humans, is definitely too slow for the purposes of automatic 
deduction, where we need to repeatedly look for applicable theorems exploring 
huge trees of different possibilities. 

The problem of speeding up matching and unification has already been ex- 
tensively studied in the theorem proving community, but in a sensibly different 
context: in particular, the knowledge base for retrieval is in that case a local 
context, subject to frequent insertions and deletions, but stably loaded in RAM. 
As a consequence, the typical solution is to store the data base of mathematical 
items in ad-hoc data-structures, particularly optimized and integrated with the 
matching algorithm, such as discrimination trees [3, 14], substitution trees [8] or 
context trees [6]. As far as we know, the feasibility of scaling-up these approaches 
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to huge, stable repositories of available mathematical knowledge (the real context 
of Mathematical Knowledge Management) has never been addressed. 

A natural way for indexing huge libraries of mathematical statements, in- 
dependently introduced in HELM [10] and Mizar [2], is that to automatically 
extract a small set of metadata from each mathematical item, providing an ap- 
proximation of its content, and devised to capture some simple invariants of first 
order matching. 

In this paper, we propose a significant improvement of the technique described 
in [10], still relying on essentially the same Metadata Set (the HELM metadata 
set, originally conceived by the first author, and first published in [17]). 

All examples, tests and statistics in this paper have been performed on the 
(HELM version) of the Coq library, composed of about 40000 mathematical 
objects. 

2 Metadata as Approximations 

For efficiency reasons, the metadata we are interested in are supposed to be ex- 
pressible in a simple relational model. This excludes, for instance, the possibility 
of indexing an object with its type or with a (complex) subterm occurring in it, 
since these are not flat data, and we would be back to the problem of efficiently 
indexing and matching this information. The only flat data we may dispose of 
are essentially occurrences of constants. The other kind of information we may 
attach to these occurrences is their actual position inside the term. So, the main 
relation of our Metadata set is a simple ternary relation of the kind 

Ref {source, tar get, position) 

stating that source contains a reference to target at the specified position. By 
suitably describing such a position we may obviously reach the same degree of 
granularity of a substitution tree (where each variable marks indeed a differ- 
ent position), thus providing a complete description of the term. However, for 
limiting memory occupation, we opted for a minimal set of “interesting” posi- 
tions, that, essentially just discriminates the root of the conclusion (we call this 
position MainConclusion) of the statement from all other occurrences. 

Example 1 . Suppose we have a statement asserting that for all x 



a; * 0 = 0 



the metadata are described by the following table: 



constant 


position 


= 


MainConclusion 


* 


InConclusion 


0 


InConclusion 
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Note that variables are not indexed (it would be very difficult to take care of 
alpha conversion). 

Example 2. Suppose to have a statement asserting that for all x, y, z 

x*{y + z) = x*y + x*z. 

Its metadata are described by the following table: 



constant 


position 


= 


MainConclusion 


* 

hline + 


InConclusion 

InConclusion 



Question: in a mathematical library, how many theorems would you expect to 
find stating an equality between two different terms containing only * and +? 

As far as we are concerned with matching in backward reasoning, i.e. with 
the problem of finding generalizations of a given goal, indexing the conclusion of 
statements is enough. For this reason, in the rest of the paper we shall essentially 
work with the few metadata introduced above. 

However, for other operations, like e.g. interactive support to forward rea- 
soning, the HELM metadata set also supports indexing of hypotheses. These 
additional metadata are also useful in all those cases where the conclusion of 
the statement does not hold enough information to allow a sensible indexing. A 
typical, pathological case is e.g. the induction principle for natural numbers, or, 
more generally, the elimination scheme for an inductive type: the conclusion is a 
generic universal assertion containing no constant at all. On the other side, the 
hypothesis, listing both the type of the inductive predicate and of the eliminated 
data, usually provide enough information for an efficient retrieval. 

The interested reader is referred to [17, 10] for an exhaustive description of 
the HELM Metadata Set. 

3 Matching Conclusions 

The problem of matching (for backward reasoning) consists of finding general- 
izations of a given goal G, i.e. of finding all those theorems in the repository 
which can be profitably applied to the given goal. If the theorem T has a shape 
of the kind Va;i, . . . , a;„.G', the problem consists to look for a substitution cr 
such that G' a can be unified with G (typically, via first order unification). Since 
substitution can only instantiate terms (and cannot erase any subterm), every 
constant occurring in G' must already occur in G: we call these constraints 
almost constraints"^. 



^ We adopted the terminology of Mizar. In particular, the only constraints and must 
constraints of [17, 10] are respectively renamed into utmost constraints and atleast 
constraints. 
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Definition 1. An atmost constraint is a set of constants atmost{ci, . . . , c„}. A 
statement s satisfies the constraint if all constants occurring in the conclusion 
of s are in atmost{ci, . . . , c„}, that is if 

{x\Ref{s, X, InConclusion) V Ref{s, x, M ainC onclusion)} C {ci, . . . , c„}. 

In this case we shall write s<{ci, . . . ,c„}. We shall also write s<c{ci, . . . ,c„} if 
c< {c, Cl, . . . , c„} and c is the (unique) constant with position M ainC onclusion. 

Checking that a theorem s meets an atmost constraint with our metadata 
is not a very simple operation: it requires a query to the data base and then 
an explicit comparison of two sets (for each theorem to test). According to our 
measures, the cost of checking an atmost constraint is in fact comparable to the 
cost of a direct unification check provided the theorem s is already in memory. 
In fact, the real point of atmost constraints (not so well explained in [10]) is not 
to speed up filtering, but to avoid loading useless objects in the central memory. 
The latter can be a very expensive operation, especially if it requires parsing, 
type-checking or, even worse, downloading via web). 

In any case, if we had to iterate the application of an atmost constraint to 
the whole library we would be back to the same scalability problem we started 
with. 

Things are a bit better if we assume to work in a “first order setting” , that is 
quite typical of automatic tactics even in higher order systems. In this case, we 
may assume that the head operator of the current goal G is already instantiated, 
and thus it must appear (again in head position) in any generalization G' . So, 
with no loss of generality, we may restrict our search to the set of theorems 
sharing the same predicate of the goal (in position MainConclusion) . 

Example 3. Suppose we are interested in looking for theorems matching the goal 
0 < S'(O). We search for theorems having < in MainConclusion and with 0 and S 
as atmost constraint. In the Coq library, composed of about 40000 mathematical 
items (theorems, definitions, inductive types, . . .), we have 263 theorems with < 
in MainConclusion. Although this provides a significant reduction of the search 
space, iterating the evaluation of the atmost constraint for 263 times is a really 
expensive operation (especially in tactics for automatic theorem proving). 

The table in Figure 1 gives the ordered list of the (top 20) constants ap- 
pearing in the Coq library in position MainConclusion, together with their fre- 
quency. 

The diagram in Figure 2 associates to each theorem of the library (a;-line) the 
number of other theorems sharing with the former the same constant in Main- 
Conclusion (y-line); the big pick on the left is of course due to Leibniz-equality. 
The average value is about 596 that also provides a reasonable estimation of the 
average number of times we may expect to iterate the computation of an atmost 
constraint in a generic query! 
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n 


frequency 


object 


1 


3978 


Coq/Init /Logic/ eq . ind#xpointer (1/1) 


2 


920 


Coq/Init/Logic/not . con 


3 


753 


CoRN/algebra/CSetoids/cs_eq. con 


4 


557 


CoRN/algebra/CSetoids/cs_crr . con 


5 


438 


Coq/Init /Logic/ ex . ind#xpointer (1/1) 


6 


435 


Sophia-Antipolis/Functions_in_ZFC/Functions_in_ZFC/Ens . con 


7 


421 


Sophia-Antipolis/Functions_in_ZFC/Functions_in_ZFC/IN . con 


8 


413 


CoRN/ algebra/ CDrdF ields/leEq . con 


9 


366 


Nijmegen/Coqob£m/Coqoban_engine/Board. ind#xpointer (1/1) 


10 


354 


CoRN/algebra/CSetoids/Ccsr_rel . con 


11 


353 


Coq/Init/Datatypes/nat . ind#xpointer(l/l) 


12 


350 


Coq/Init /Logic/ or . ind#xpointer (1/1) 


13 


333 


Coq/Init/Specif /sumbool . ind#xpointer (1/1) 


14 


328 


Sophia-Antipolis/Algebra/Sets/Equal . con 


15 


303 


Coq/Init /Logic/and. ind#xpointer (1/1) 


16 


280 


CoRN/algebra/CSetoidFun/PartFunct . ind#xpointer (1/1) 


17 


263 


Coq/Init/Peano/le . ind#xpointer (1/1) 


18 


247 


Coq/ZArith/zarith_aux/Zle . con 


19 


245 


CoRN/ algebra/ CLogic/CProp . con 


20 


245 


Coq/Reals/Rdef initions/Rle . con 



Fig. 1. Top 20 operators appearing in position MainConclusion 




Fig. 2. Diagram associating to each theorem of the Coq-library (a;-line) the number of 
other theorems sharing with the former the same constant in MainConclusion (j/-line) 
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4 Atleast Constraints 

A way for improving the initial filtering (preliminary to the application of an 
almost constraint) is by requiring that more symbols of the current goal G occur 
in the conclusion of the theorem we are looking for; we call these constraint atleast 
constraints. 

Definition 2. An atleast constraint is a set of constants atleast{c\, . . . ,Cn\. 
A formula s satisfies the constraint if all the constants {ci, . . . ,c„} are in the 
conclusion of s, that is if 

{ci, . . . , c„} C {a;|i?e/(s, x, InC onclusion)} . 

In this case we shall write {ci, . . . , c„} < s (and {ci, . . . , c„} s if c is the 
constant in position MainC onclusion of s. 

The interest of atleast constraints is that in order to find all theorems satis- 
fying a given constraint {ci, . . . , c„} it is enough to compute 

{x\Ref{x,Ci, InC onclusion)} 

that is a simple n-ary join operation in a relational DB. 

On the other side, the big problem of atleast constraint is that they can po- 
tentially cut-off usefull theorems. Consider for instance, the goal is 0 < S'(O). We 
could probably expect to find in the library, and to apply, a theorem stating that 
Va;.0 < X (provided we are talking about natural numbers). So, we may restrict 
ourselves to all those theorems having < in position MainConclusion and 0 in po- 
sition InConclusion, that is imposing 0 as atleast constraint (there are just 36 of 
them in the whole library) . However, the same goal could also have been proved 
by a direct application of a theorem stating that '^x.x < S{x) (such a theorem 
can be actually found in the Coq library: cic : /Coq/Arith/Le/le_n_Sn. con); 
obviously, {0} ^le_n_Sn.con an the latter theorem would not be found by the 
above query. 

The theorems containing < in MainConclusion and satisfying {S'} as atleast 
constraint are 98. The union of this set with the previous 36 theorems give a 
set of 99 theorems (35 theorems contain both 0 and S). This is still a sensible 
improvement w.r.t the initial 263 candidates, but, alas, we are still neglecting 
all those theorems just containing < in MainConclusion, and nothing more, such 
as, for instance, the transitivity of <. 



5 Exactly Constraints 

The considerations at the end of the previous section suggests a different ap- 
proach to the computation of almost constraints . First of all, we need the notion 
of exactly constraint. 
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Definition 3. An exactly constraint is a set of constants exactly {ci, ... ,c„}- 
A formula s satisfies the constraint if the constants {ci, . . . ,c„} are exactly the 
constants appearing in the conclusion of s, that is if 

{ci, . . . , c„} = {x\Ref{s, X, InC onclusion)} . 

In this case we shall write {ci, . . . , c„} ixi s (and {ci, . . . , c„} t<ic s if c occurs 
with position MainC onclusion in s. 

The first important fact is that 

t C* ^ G [J {x\x t<ic P} 

PCC 

that is t contains at most a set C of constants if and only if for some subset 
P oi C, t contains exactly the constants in P (in the next section we shall see 
that not every subset of C has to be taken into account). The second important 
consideration is that exactly constraints may be efficiently conputed by a simple 
extension to the metadata set. The new relation 

no-Concl{source, no) 

associates to each statement source the number no of different symbols in its 
conclusions (the new table can be computed in few seconds from the already 
available metadata). Then we have 

t cCc {ci, . . . , c„} {ci, . . . , c„} <c t A no-Concl{t, n) 

that is t contains exactly {ci, . . . , Cn} if and only if it contains at least {ci, . . . , 
c„}, and it just contains n constants. 

Example 4- Retrieving candidates for matching the theorem 0 < 5'(0) amounts 
to the execution of four SQL queries, corresponding to the four exactly con- 
straints specified by the sets 0, {0}, {S'} and (0, S|. The cardinality of the 
respective result set (for the Coq library) is given in the following table: 



exactly constraint 


#result 


0 


60 


{0} 


1 




15 


{0,S| 


5 


total 


81 



Example 5. Suppose we have the goal a; + 0 =nat x. The equality we are dealing 
with is Leibniz equality, and nat is an explicit constant appearing in the goal. 
So, in this case, matching the goal, amounts to solve the exactly constraints 0, 
{nat}, {0}, {+}, {nat, 0} {nat, S|, (0, S| and {nat, 0, S| with results sets as 
described in the following table: 
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exactly constraint 


#result 


0 


195 


{nat\ 


81 


{0} 


0 


{+} 


0 


{nat, 0} 


46 


[nat, -1-} 


9 


{0i+} 


0 


{nat, 0, -I-} 


9 


total 


340 



In this case, the total number of 340 should be compared against the num- 
ber of theorems satisfying an empty atleast constraint (with Leibniz equality in 
MainConclusion), that is 3978. 

Remark 1. It never happens, in practice, that constants occur inside the conclu- 
sion of an equality statement if the type of the equality is not instantiated as 
well. This simple strategy allows to spare the three queries with an empty result 
set in the example above. 

Given an exactly constraint, the corresponding SQL query is generated in a 
straightforward way; for instance the SQL query corresponding to the exactly 
constraint {nat, 0, -I-} has the following shape: 

select ref Obj . source 

from ref Obj , ref Obj as refObjl, 
refObj as ref Obj 2, ref Obj as refObjS, no_concl 
where 

ref Obj .occurrence 

="cic : /Coq/Init/Logic/eq. ind#xpointer (1/1) " and 
ref Obj .position="MainConclusion" and 
ref Obj 1 . occurrence 

="cic : /Coq/Init/Datatypes/nat . ind#xpointer (1/1) " and 
ref Obj 1 .position="InConclusion" and 
ref Ob j 2 . occurrence 

="cic : /Coq/Init/Datatypes/nat . ind#xpointer (1/ 1/1) " 
ref Obj 2 .position="InConclusion" and 
ref Ob j 3 . occurrence 

="cic : /Coq/Init/Peauio/plus . con" 
ref Ob j 3 . posit ion=" InConclusion" and 
ref Obj . source = ref Obj 1 . source and 
ref Obj 1 . source = ref 0bj2 . source and 
refObj 2 . source = ref 0bj3 . source and 
ref Obj 3. source = no_concl . source and 
no_concl.no = 3; 
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The big question is of course how many different sets of exactly constraints 
we may be forced to generate for matching a given goal. If we have n constants 
in the goal, this is obviously bounded by 2", that is the cardinality of all possible 
subsets of a set with n elements. 

Thus it becomes interesting to know what could be an “expected” value for 
n, and the only sensible way to provide an estimation is again to rely on the 
library itself. 

The table in Figure 3 gives, for several classes of terms, the repartition of the 
theorems according to the number n of constants in their conclusion (comprising 



n 


all 


= 


— nat 


= R 


cs-eq 


< 


Rle 


leEq 


1 


12635 


195 






9 


60 


36 


27 


2 


6001 


332 


81 


31 


10 


84 


58 


1 


3 


4049 


616 


132 


57 


8 


54 


78 


94 


4 


3000 


1017 


203 


122 


13 


24 


23 


31 


5 


2323 


763 


174 


90 


3 


19 


16 


15 


6 


1226 


395 


78 


45 


22 


10 


10 


10 


7 


875 


216 


48 


38 


22 


6 


8 


5 


8 


769 


135 


20 


41 


44 


1 


2 


9 


9 


496 


65 


15 


35 


69 


1 


4 


13 


10 


1167 


54 


8 


25 


74 


2 


0 


36 


11 


469 


50 


5 


10 


94 


0 


5 


9 


12 


444 


23 


1 


4 


83 


2 


1 


40 


13 


312 


24 


3 


9 


69 


0 


1 


34 


14 


228 


18 


3 


2 


68 


0 


1 


23 


15 


155 


12 


0 


3 


51 


0 


1 


15 


16 


89 


4 


0 


0 


29 


0 


1 


6 


17 


90 


8 


0 


1 


21 


1 


0 


8 


18 


66 


5 


0 


1 


15 


0 


0 


12 


19 


56 


5 


0 


0 


7 


1 


0 


9 


20 


38 


6 


2 


0 


13 


0 


0 


6 


21 


51 


10 


0 


1 


7 


0 


0 


2 


22 


28 


4 


0 


0 


9 


0 


0 


3 


23 


27 


9 


0 


0 


4 


0 


0 


1 


24 


15 


5 


1 


0 


1 


0 


0 


0 


25 


14 


6 


1 


0 


1 


0 


0 


0 


26 


15 


3 


0 


0 


4 


0 


0 


4 


27 


8 


0 


0 


0 


2 


0 


0 


0 


28 


2 


0 


0 


0 


0 


0 


0 


0 




















40 


3 


0 


0 


0 


0 


0 


0 




tot. 


34661 


3978 


775 


515 


753 


263 


245 


413 


av. 


3.3 


4.9 


4.7 


5.8 


10.2 


2.7 


3.5 


8.9 



Fig. 3. Repartition of theorems with respect to the number of different constants in 
their conclusion 
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the constant with position MainConclusion) . The first column refers to the whole 
library; the other columns are snapshots relative to the statements with the 
specified MainConclusion. 

The average number of different constants appearing in the conclusion of 
statements of the Coq library is surprisingly low: 3.3. Things are a bit worse for 
equality statements, but we are also counting the type, and thus, according to 
Remark 1 the value in Figure 3 should be decremented by one. 

Let us finally remark the quite anomalous behaviour of the setoid equality 
cs.eq and the algebraic less or equal relation leEq of the C-CoRN development 
in Nijmegen. The problem is that in this case the formal statements are cluttered 
by a long series of coercions taking in charge the hierarchy of structures typical 
of algebraic developments. It could be possible that coercions should deserve 
a special treatment for indexing purposes (we are currently investigating the 
issue). 



6 Prefixes 

Not every subset of the constants appearing in the conclusion of a goal G should 
be considered for the generation of exactly constraints: we should only take into 
account subsets appearing in some prefix-tree of G. We say that t' is a prefix- 
tree (simply, a prefix) of t if t' can be obtained from t by pruning subtrees 
(replaced by a special “empty” tree T); this is equivalent to the following defi- 
nition 

Definition 4. The set P{t) of prefixes of a tree (a first order term) t is defined 
by the following rules: 

— T S P{t) for any tree t; 

— if t = c(<i, . . . ,tn), and for z = 1, . . . , n t' € P{ti), then c(t^, . . . ,t'^) € P{f). 



Example 6. Gonsider the goal S'(O) * x < y. The set of prefixes (neglecting vari- 
ables) is {T,T < T,T * T < T,5'(T) * T < T,S'(0) * T < T}. In particular, 
we cannot have a prefix containing S but not *, nor a prefix containing 0 but 
not S. Any matching goal G' must satisfy the same condition, thus imposing to 
have equality in MainGonclusion, the set of exactly constraint for S{Q) * x < y 
is shown in the following table: 



exactly constraint 


#result 


0 


60 


{*} 


14 


{*,5'} 


4 


{*,5,0} 


3 


total 


81 





Efficient Retrieval of Mathematical Statements 



27 



7 Mixing Exactly Constraint and Atleast Constraints 

When, even restricting to prefixes, the total number of exactly constraints is too 
big to allow a feasible computation, we may always employ exactly constraints 
up to a given number fc — 1 of occurrences, and then requiring atleast constraints 
for all possible subsets of k constants. We call this constant k the just-factor. 
The important fact is that we have to apply atmost constraint only to the union 
of the result sets of the atleast constraints. 

Remark 2. The algorithm described in [10] can be considered as a degenerate 
case of our approach when fc = 0. 

Remark 3. While the result sets of different exactly constraints are always dis- 
joint, this in not any longer the case for atleast constraints and it is worth to 
add an additional pass to drop repetitions. 

Example 1. Consider again the previous example. If we decide to stop with a 
just-factor fc = 2, we should consider {*, S} as an atleast constraint, getting back 
14 candidates with a single query (against the 4-1-3 theorems obtained with two 
queries as above). The extra 7 candidates could be filtered out by the application 
of the atmost constraint, but these would require 14 more queries (one for each 
statement in the result set of the atleast constraint). 

Example 8. Let us consider the goal (sinPI/3) =r (cosPI/6). In Coq, the real 
number n is treated as the sum of n occurrences of 1 (i?l); so the goal contains 
the 8 constants =,R,sin,cos,div,PI,Rplus,R\. For A: = 0 we get the usual 
3978 candidates with equality in MainConclusion. The case k = 1 amounts to 
restrict the attention to the realm of real numbers, reducing the total number 
of candidates to 195 (just containing equality) plus 515 statements containing 
R (and possibly other things). On the latter 515 statements we must compute 
atmost constraint. 

For k = 2, we have the following set of constraints: 



exactly constraint 


#result 


0 


195 


{R} 


31 


atleast constraint 


#result 


{R, sin} 


59 


{R, cos} 


65 


subtotal 


124 


subtotal (distinct) 


93 


total (distinct) 


319 



Note that in this case the intersection of the result sets of the two atleast 
constraints is not empty (it contains 31 elements). At the end, we have just to 
compute atmost constraints for 93 elements: this means that in passing from a 
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just-factor 0 to a just-factor 2 we already reduced the number of queries from 
1 -p 3978 = 3979 to 4 -h 93 = 97 (2.4%). 

For higher values of the just-factor things can still improve but in a much 
less remarkable way. In particular, for A: = 3, the total number of queries is 
7 -h 51 = 58, and for A: = 4 is 12 -k 35 = 47. 



exactly constraint 


#result 


0 


195 


{R} 


31 


{i?, sin} 


0 


{R, cos} 


0 


atleast constraint 


#result 


{i?, sin, cos} 


31 


{R, sin, div} 


21 


{R, cos, div} 


23 


subtotal 


75 


subtotal (distinct) 


51 


total (distinct) 


277 



Note also that for A; = 4 the subtotal of atleast is even greater than for k = 3, 
since we have a big number of largely overlapping sets; of course the total number 
of distinct elements is eventually either stable or decreasing. 



exactly constraint 


#result 


0 


195 


{R} 


31 


{R, sin} 


0 


{R, cos} 


0 


{R, sin, cos} 


0 


{i?, sin, div} 


0 


{i?, cos, div} 


0 


atleast constraint 


#result 


{i?, sin, cos, div} 


12 


{R, sin, div, PI} 


16 


{R, sin, div, Rplus} 


19 


{R, cos, div, PI} 


16 


{R, cos, div, Rplus} 


23 


subtotal 


86 


subtotal (distinct) 


35 


total 


261 



A sensible heuristic may be based on the following consideration. Suppose 
that the Goal G has n constants in position InConclusion. Then for any k, the 
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number of different exactly constraints with more than k elements is (roughly) 

” / n\ 

bounded by p{k) = ^ I . ) . If p{k) is less than the cardinality of the result 

i=k+i \ * / 

set of atleast constraints for fc — 1 elements, it may look worth to generate and 
compute exactly constraints with k elements; passing then to fc+1. As a simpler, 
further approximation, instead of p{k) we may just use the upper bound 2". 

For the previous example we would have the following situation (we take 
n = 6, due to the special treatment of the type i?; for the same reason, in the 
case of the equality, p{k) should be compared with the result set of the atleast 
constraint at level k, and not k — 1). 



k 


p{k) 


# — mustk 


I 


63 


515 


2 


57 


93 


3 


42 


51 


4 


22 


35 



Our heuristic would suggest to go on (that is indeed the best decision) . Using 
2" = 64 instead of p{k) we would have stopped with just-factor of 3, that is in 
any case a sensible choice. More generally, taking a just-factor of 3 for equality 
statements and of 2 for all other statements seems to be a very simple but quite 
effective politics. 

The evaluation and tuning of the above heuristics is currently under way. 



8 Conclusion and Future Work 

In this paper we introduced a very simple but extremely effective extension of 
the approach described in [10] for the retrieval of statements matching a given 
goal G. Our extension is essentially based on two simple remarks: 

1. an atmost constraint constraint C may be reduced to a union of exactly 
constraints over subsets of C; 

2. an exactly constraint C can be simply implemented as a join of the atleast 
constraint C, with the fact that the statement must contain a number of 
constants equal to the cardinality of the C. 

Even with very simple heuristic methods, our approach reduces the average 
matching time of more than ten times. 

There are also additional benefits. 

First of all, the approach described in [10] becomes practically useless in case 
the goal to match contains metavariables, since in this case the onlyc (responsible 
for the actual filtering) makes no sense. We have a similar problem, in our case, 
but much less dramatical since the onlyc would be applied (if required) to a 
much more smaller sets of candidates, and renouncing to this filter does not look 
problematic. 
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A second important benefit is that our approach allow to order the resulting 
candidates according to the dimension of the prefix of G they are matching: the 
general idea is that a statement matching a bigger prefix is likely to be a better 
candidate (thus, e.g., in the case of the equality in MainConclusion, leaving 
symmetry and transitivity as a last resource) . 

From the point of view of automatic proving, our technique, although far 
from being resolutive, has substantially improved the automatic tactics under 
development in HELM, solving part of the problems, and helping to put in 
evidence the new and crucial weakness of the current approach: the large number 
of theorems having just one constant in MainConclusion and nothing else. For 
instance, in the case of equality we have 195 different theorems with a conclusion 
of the kind n =x iti- Typical examples are, for instance^: 

SingletonJnv stating that x is equal to y provided x is an element of {y}: 

Wx,y: U.x & {y} ^ x =u y 

fun.item stating that u is equal to v provided that they are the n-th element 
of a same list e: 

Vu, V : AS/e : List. 'in : nat.{item u e n) =a {item v e n) ^ u =a v 

Lub_is_unique stating that a =jj b provided that {U is a conditionally com- 
plete partial order and) a and b are least upper bounds of a same subset C 
of U. 



VC : {Ensemble U).ia, b : U.{Lub C a) =u {Lub C b) ^ a =u b 

Theorems of the previous kind always match any equality goal; if moreover, 
as it is often the case, they generate one or more equality subgoals, we may easily 
expect an exponential explosion of the search-tree with a branching factor close 
to 100! 

Several heuristic may be imagined to solve this problem, but this a completely 
different story that we plan to tell in a forthcoming paper. 
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Abstract. We present a formalization of the axiomatic set theory ZF 
which reflects real mathematical practice, and is easy for mechanical 
manipulation and interactive theorem proving. Unlike the standard first- 
order formalizations, our version provides a rich class of abstraction terms 
denoting sets on the one hand, and is based on purely syntactical (rather 
than semantic) considerations on the other hand. 



1 Introduction 

Official formalizations of the axiomatic set theory ZF in all textbooks are based 
on some standard first-order language. In such languages terms are variables, 
constants, and sometimes function applications (like xC\y). What is not avail- 
able in them is the use of abstraction terms of the form {x \ ip}. On the other 
hand all modern texts in all areas of mathematics (including set theory!) use 
such terms extensively. For the purpose of mechanizing real mathematical prac- 
tice (including automated or interactive theorem proving), and for mathematical 
knowledge management in general, it is therefore important to have a formal- 
ization of ZF which allows the use of such terms (and provides all other types 
of notation regularly employed in set theory). 

Now, abstraction terms are used, of course, in textbooks on first-order ZF (as 
well as in several computerized systems). However they are always introduced 
(at least partially) in a dynamic way, based on the “extension by definitions” 
procedure (see [7]): In order to be able to introduce some abstraction term it 
is necessary to first justify this introduction by proving a corresponding exis- 
tence theorem in ZF (or some extension by definitions of ZF). The complete 
separation we have in first-order logic between (the easy) check whether a given 
expression is a well-formed formula, and (the difficult) check whether it is a 
theorem, is thus lost. The main novelty in what we present in this paper is a 
language with abstraction terms which is static, so that the above mentioned 
separation is kept, and which is at the same time complete, in the sense that for 
every instance of the comprehension schema which is provable in ZF, there is a 
corresponding term which denotes the set whose existence is guaranteed by that 
instance. 

Ideally, we would like to allow every formula ip to be used for forming an ab- 
straction term (according to the naive comprehension principle). Unfortunately, 
it is well known that this would lead to paradoxes. Historically, the guiding line 
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behind the choice of those instances of the comprehension principle which are ac- 
cepted in ZF has been the “limitation of size doctrine”, according to which only 
a collection which is not “too big” forms a set ([4, 5]). However, this criterion is 
not constructive: nobody has ever suggested an effective procedure, which given 
a formula decides whether the collection of all the objects which satisfy it is not 
“too big”. Accordingly, ZF uses instead some constructive principles to select 
formulas which intuitively seem to meet this criterion. These principles are usu- 
ally explained and justified ([8]) on semantic grounds, using certain general onto- 
logical assumptions. To attain the goal of this paper we should use instead purely 
syntactical (rather than semantic) criteria for characterizing a sufficient big class 
of formulas which one can safely use (according to ZF) in such abstractions. For 
this purpose, we use a safety relation >~zf between formulas and finite sets of 
variables^. The intended meaning of “The formula ip{xi, ... ,Xn,Vi, ■■■ ,yk) is 
safe with respect to {xi, . . . ,x„}” {y}{xi, . . . , a;„, yi, . . . ,yk) Fzf {x\, . . . ,x„}) 
is that for any assignment of concrete sets to the parameters yi,. . . ,yk, the class 
denoted by {(xi, . . . , Xn) | is a set. In particular: If (p{x) >~zf x then the class 
{x I (fi{x)} denotes a set (this particular case is what interests us, but in order 
to define it appropriately we need to extend it to the more general relation). 

2 The System and Its Language 

2.1 Language 

The formal definition of our language is the following (where Fv(exp) denotes 
the set of free variables of exp): 

Terms: 

— Every variable is a term. 

— The constants 0 and w are terms. 

— If a; is a variable, and is a formula such that p >~zf {a^}, then {x \ p} 
is a term (in which the variable x is bound). 

Formulas: 

— If t and s are terms then t = s, t G s and t C s are formulas. 

— li ip and if are formulas, and x and y are variables, then ^p, (p A tp), 
{p V Tp), and 3xp are formulas. 

The Safety Relation Fzf- 

1. p >~zF ^ for every formula p. 

2. X = t >~zF {x}, t = X >~zF {a;}, x € t >~zf {x}, and x Ct >~zf {a:} if x 
is a variable, t is a term, and x ^ Fv{t). 

3. p\/ Ip >ZF X ii p >~ZF X and ip >ZF X. 



^ The idea of safety comes from database theory ([1,9]). See [3] for the general idea 
of safety relations and its connections with database theory. 
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4. (/? A V' ~!~ZF X UY if (f >~ZF X, Ip )~ZF Y and either Y n Fv{(p) = 0 or 
XnFv{p;) = 0 . 

5. 3yip >-zF X - {y} ify € X and ip >~zf X. 

6. 3yp A yy{p ip) >~zf X if ip >zf X, y G Fv{p), and X n Fv{p) = 0. 

Notes: 

1. Officially, our language does not include the universal quantifier V and the 
implication connective — Accordingly, in the last clause and below they 
should be taken as defined (in the usual way) in terms of the official connec- 
tives and 3. 

2. From clauses 1 and 4 in the definition of )^zf it follows that if p >zf X or 
Ip )~ZF X, then p f\ip ^zf X. 

By inspecting the mutual recursive definitions of the sets of terms and for- 
mulas, and of the safety relation ^zf, it is not difficult to prove the following 
two propositions: 

Proposition 1. >~zf has the following properties: 

— If p >zF X then X C Fv{p). 

— If p )^zF X and Z C X, then p )^zf Z- 

— If p >~zF {xi, • ■ • , Xn\ and Ui, . . . are n distinct variables not occurring 
in p, then p{vi/xi, . . . ,u„/a;„} >zf {ffi, ■ ■ • ,Vn}- 

Proposition 2. There is a recursive algorithm which given a string of symbols 
determines whether it is a term of the language, a formula of the language, or 
neither, and in case it is a formula p returns the set of all X such that p >~zf X. 

2.2 Logic 

Basically, the logic we will use in our system is the usual first-order logic with 
equality. One should note however the following differences/additions: 

1. Our language provides a much richer class of terms than those allowed in 
orthodox first-order systems. In particular: a variable can be bound in it 
within a term. The notion of a term being free for substitution should be 
generalized accordingly (also for substitutions within terms!). As usual this 
amounts to avoiding the capture of free variables within the scope of an op- 
erator which binds them. Otherwise the rules/ axioms concerning the quan- 
tifiers and terms remain unchanged (for example: Wxp —>■ p(tjx) is valid for 
every term t which is free for a; in i^) . We also assume a-conversion to be a 
part of the logic. 

2. The substitution of equals for equals is allowed within any context (under 
the usual conditions concerning bound variables). 

3. In analogy to the previous rule concerning identity of terms, we may assume 
similar rule(s) allowing the substitution of a formula for an equivalent for- 
mula in any term or formula in which the substitution makes sense (again. 
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under certain conditions which will not be specified here)^. This would en- 
able us, e.g., to replace the first extensionality axiom Exl below by the 
following analogue of the (77) rule of the A-calculus: 

x = {y\y Gx} 

(because with substitution of equivalents Vz(z G x z G y) would imply 
{z \ z G x} = {z \ z G y}, and so, by (77), that x = y). 

2.3 The System ZF~^ 

Now we present the axioms of ZF~^, our version of ZF: 

Extensionality Axioms: 

Exl xCyAyCx^x = y 
Ex2 zGxAxQy^zGy 
Ex3 X C y\/ Bz(z G X A z ^ y) 

The Comprehension Schema: 

— Vx(x G {x \ ip} GG' Lp) 

Peano’s Axioms: 

- 0 G w 

— X G ui ^ {z \ z = x\/ z G x} G to 
— Vx{x ^ 0 ) 

— {% G y A Vx(x G y ^ {z \ z = x\/ z G x} G y)) ^ to Q y 

Other axioms: 

— The axiom of choice 
— The regularity axiom 



3 The Connection Between ZF and ZF~^ 

The main theorem of this paper is that ZF~^ and ZF are equivalent. For this 
(and in order to clarify the connections between the comprehension axioms of 
ZF and ZF~^), we introduce first an intermediate system, ZF*, of which ZF~^ 
is obviously an extension. Then we split the main theorem into Theorems 1 and 
2 below (which together show the equivalence of all three systems). 



^ It makes sense to demand also that if p is equivalent to ip, Fv{p) = Fv{ip), and 
p Azf X, then ip >~zf X. However, the crucial decidability of the safety relation 
will be lost if such a clause will be added to its definition. Still, it might be useful 
to add some particular important cases of this principle to the definition of safety. 
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Definition 1. Let ZF* be the system obtained from ZF by replacing its stan- 
dard comprehension axioms (pairing, powerset, union, separation, and replace- 
ment) by the following safe comprehension schema: 

(SCn) 3Zyx{x € Z ip) 

where p is in the language of ZF, p >~zf {a^}; and Z ^ Fv{p). 

Theorem 1. Every theorem of ZF is also a theorem of ZF*. 

Proof. We prove that the standard comprehension axioms of ZF can be proved 
in ZF*. 

Pairing: \~zf* 3Zyx{x GZ^x = yVx = z), since {x = yV x = z) >~zf {x} 
by clauses 2 and 3 of the definition of Fzf- 

Powerset: hzF* 3ZNx{x G Z ^ x C z) since x C z Fzf {x} by clause 2. 

Union: \~zf' 3ZNx{x G Z 3v{x G vhv G y)) since 3v{x G vhv G y) Fzf {x} 
by clauses 2, 4, and 5. 

Separation: \~zf* 3Zyx{x GZ^xGyAp) since {x G y A p) >~zf {x} by 
clauses 1, 3, and 4 (see second note after the definition of >~zf)- 

Replacement: This is the only problematic axiom to prove. The reason is that, 
unlike the other comprehension axioms of ZF, the official formulation of 
replacement in the language of ZF has the form of a conditional: 

(iy3v'ix{p 4A X = v)) ^ 3ZVx(x G Z 4A 3y(y G w A p)) 

where v,w,Z ^ Fv{p). To prove this in ZF* , let A abbreviate the formula 
yx{p AA X = v). Reasoning in ZF*, assume VyduA (this is the left hand side 
of the implication we want to prove). This and the definition of the formula 
A logically imply: 

{3vA A Vu(A X = v)) AA p 

But 3vA A \/v{A X = v) Fzf {x} (by clause 6 of the definition of Fzf), 
whence 

3y{y G w A {3vA A Vu(A x = v))) Fzf {a^} 

Thus SCn implies: 

3Zyx{x G Z AA 3y{y G w A 3vA A Vu(A ^ x = v))) 

The last two conclusions entail 3ZVx(x G Z AA 3y{y Gw A p)). 

Theorem 2. Every theorem of ZF~^ in the language of ZF is a theorem of ZF. 

Proof. For simplicity, we assume that 0, oj, and C are in the language of ZF 
(together with the relevant axioms). We define recursively for every formula p 
of ZF~^ a translation pAl into the language of ZF such that Fv{p^^'^) = Fv{p): 
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— If is an atomic formula in the language of ZF then = (p. 

— Suppose ip is an atomic formula which contains an abstraction term. Let 
t = {x \ tjj} (where rp z f x) he a, maximal abstraction term of p. Define: 

= 3Z{yx(x eZ4P A {p{z/t))^^'^) 

where Z is a new variable, and p{Zjt) is the formula obtained from p by 
replacing every occurrence of t in by Z. 

~ Let {p (Vxp)^^^ = yx{p)^^^ etc. 

Next, we show how to express an analogue (which is actually an extension) 
of Fzf within the language of ZF. For this we need some useful notations (in 
the language of ZF): 

— z = {x} =Df X G z A yy{y G z ^ y = x) 

— z = {x, y}=DfxGzAyGzA Vw(w Gz^w = xyw = y) 

— z = (x) =uf z = X 

— z = {x,y) =Df 3u3v{z = {u, v} Au = {x} Av = {x, y}) 

— z= {xi,...,Xn) =Df 3y(z = {xi,y) Ay = (x 2 , . . . , x„)) for n > 3. 

— (xi, . . . , x„) G z =Df 3y{y G z A ?/ = (xi, . . . , x„)) 

It is easy to see that (xi, . . . , x„) G z )^zf {a^i, ■ • ■ , x„}. 

Let setxi,...,x„P be 3ZVxi . . . Vx„((xi, . . . , x„) G Z GA p) for n > Q, {p ^ 
p) for n = 0 Let Setxi,...,xnP be the universal closure of setxj,...,xnV- Note 
that SetxP formalizes the application to p of the comprehension principle. We 
show now by induction on the structure of a formula p of ZF~^ that if p >~zf 
{xi, . . . ,x„} then Setxj^,...,x„P^^'^ is a theorem of ZF.^ 



1. The case n = 0 is trivial. 

2. (a) If t is a variable or a constant of ZF then 

— setxX = t and setxt = x follow from the pairing axiom. 

~ setxX G t is a logically valid formula. 

— setxX C t follows from the powerset axiom. 

(b) If t = {y I V'} (where ip >~zf y) and p = p{x,t), where p{x,t) is in 
{x = t, t = x,x G t,x C f}, and x ^ Fvpt) (= Fv{ip) — {j/}), then 
pW = 3Z(pyy{y G Z GA Ap{x, Z)). By induction hypothesis for ip we 
have \~ZF Setytp^^h This means that \~zf 3Z(V?/(?/ G Z and so 

\~ZF 3!Z(V?/(?/ G Z GA 'tp^^'>). By part (a) we have also \~zf Setxp{x, Z). 
It is easy, however, to show that \~zf {3\Zp A Setx'ip) Setx3Z{p A ip) 
in case x ^ Fv{p). This implies that \~zf SetxP^^^- 

3. setxi,...,x„{y y follows from setxi....,xn^^^'^ and setxi,...,xn'4’^^'^ by the 
axioms of union and pairing. 



® This is a generalization of the notation Set^p from [7]. 

^ The converse is not true. Thus Setx(x 7 ^ x) is a theorem of ZF, but x 7 ^ x {x}. 
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4. To simplify notation, assume that Fv{ip) = {x,z}, Fv{tp) = {x,y,z}, and 

that (f >~ZF { 2 :}, V' >~ZF {y} (and so ip A tp >zf {x,y})- By induction 
hypothesis, \~zf and \~zf Sety-ip^^P We show that Set^^yip AtpY^'> 

is provable in ZF. Reasoning in ZF, the assumptions imply that there are 
sets Z(z) and W(x,z) such that x G Z{z) and y G W{x,z) AA 

Hence {{x,y) \ ((/? A = Uxgz(^){(^> I V ^ W{x,z)}. Set^^y{(p Aip)^^'> 

follows therefore by the axioms of replacement and union. 

5. We leave it to the reader to show that Setx-{y}^yp^^^ follows in ZF from 
SetxP^^^ ■ 

6. Assume that \~zf y G Fv{(p), and {x\, , Xn}A\Fv{'p) = 0. 

We show that \~zf A ^ This is immediate from 

the fact that if {xi, . . . ,x„} n Fv{p) = 0 and y G Fv{(p) then the formula 
dj/Vxi . . . Xnii^yp A Vy((/3 ^ tp)) ip) is logically valid®, together with the 
following lemma (which is interesting on its own right): 

Lemma: Assume that {yi, . . . ,yk} C\ Fv{ip) = 0, \~zf setxi,...,x„'ip and 
3j/i, . . . , j/fcVa;i, . . . ,Xn{p ip) is logically valid. Then \~zf setxi^...,x^p- 

Proof of the Lemma: 3j/i, . . . , j/fcVxi , . . . , Xn{p ^ ip) logically implies the 
formula 3yi , . . . , yk^xi , . . . , Xn{<p AA ip A {ip ^ <p)). It is easy however to see 
that if {yi . . . yk}r\Fv{(p) = 0 then logically follows in first order 

logic from Setxi,...,x„<P and 3j/i . . . yk^x\ . . . Xn{p AA (p). Hence we only need 
to prove that setxi^...,x„{ip A {ip ^ ip)) follows in ZF from setxi^...,xn'4’- But 
this is an instance of clauses 4 and 1. 

We show now that if \~zf+ f then \~zf . Since obviously = p 
in case p is in the language of ZF, this will end the proof of the theorem. 
Now the inference rules are essentially identical in the two systems, and our 
translation preserves applications of these rules. It suffices therefore to show 
that the translations of the axioms of ZF~^ are theorems of ZF. We leave the 
reader the easy task of showing this for Peano’s axioms, and show here the case 
of the comprehension schema. Well, \i p >~zf x then the translation of this 
schema for p is Wx{3Z{'ix{x G Z AA p^^'>)Ax G Z) AA p^^^). Now it is easy to see 
that this formula follows in ZF from SetxP^^'^ ■ However, the latter is provable 
in ZF by what we have proved above (since p >~zf x). 



Theorem 3. ZF^ , ZF* and ZF are all equivalent: 

— ZF* and ZF prove the same theorems. 

— ZF^ , ZF* and ZF prove the same theorems in the language of ZF. Hence 
ZF+ is a conservative extension of ZF. 

— Any formulas of the language of ZF~^ has a translation p^^^ into the language 
of ZF in the sense that \~zf+ P AA p^^'> . 



For the proof of the validity of this formula show that it follows from 3yi . . .ytp as 
well as from Syi . . . ykP- 



5 
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Proof. Obviously, the comprehension schema of ZF~^ implies (SCn) (the com- 
prehension schema of ZF*). Since the usual infinity axiom is easily provable in 
ZF+ too, it follows that every theorem of ZF* is also a theorem of ZF'^. This 
fact, together with theorems 1 and 2, entail the first two parts. It is not difficult 
to see that from the proof of theorem 2 satisfies the third one. 



4 The Expressive Power of ZF~^ 

4.1 Standard Notations for Sets 

In the language of ZF~^ we can introduce as abbreviations (rather than as ex- 
tensions by definitions) all the standard notations for sets used in mathematics. 
Again, all these abbreviations should be used in a purely static way: no justifying 
propositions and proofs are needed. Here are some examples: 

— {ti, . . . , tn} =Df{x\x = ti\/...\/x = tn} (where x is new). 

— (t,s) =Df 

— {x € t \ if} =Df {x \ X € t A if} (where x ^ Fv{t)). 

— {t \ X G s} =uf {y \ 3x{x G s Ay = t)} (where y is new, and x ^ Fv{s)). 

— {t{xi, ...,Xn) I (/?} =Df {y I 3xi, . . .,Xn{y = t A (fi} (where y is new, and 
P Fzf {a;i, ■ • -,Xn})- 

— V{f) =Df {x \ X Ct} (where x is new). 

— s'zt=Df{x\ 3a3b{a G s A b G t A x = (a,b))} (where x, a and b are new). 

— sUt=Df{x\xGs\/xGt} (where x is new). 

— snt=r)f{x\xGsAxGt} (where x is new) . 

— S{x) =Df xU {x} 

~ =Df {x \ 3y{y GtAx Gy)} (where x and y are new). 

“ C\t=Df{x\ 3y{y G t) A\/y{y G t ^ x G y)} (where x and y are new). 

It is straightforward to check that in all these abbreviations the left hand 
side is a valid term of ZF~^ (provided that the terms/formulas occurring in it 
are valid terms/ well-formed formulas of ZF~^). 

Note. There are two points about these definitions which are worth mentioning: 

1. The validity of the term s x t is due to the fact that 

3a3b{a G s Ab G t Ax = {a,b) )~zf x). 

This fact does not depend on the demand that x C y >~zf x. Hence the fact 
that the existence of Cartesian products does not depend on the powerset 
axiom is reflected here by the obvious definition of a Cartesian product. 

2. Our term for is valid (and so denotes a set) whenever t is valid. It is 
easy to see that if t denotes a non-empty set A then p| t indeed denotes the 
intersection of all the elements of A. On the other hand, if the set denoted by t 
is empty then the same is true for the term fj t (such definition of intersection 
is known in the literature, e.g. in [6], but unlike here, it is done there by force). 
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4.2 Function Terms and the A-Notation 

In the language of ZF^ we can introduce as abbreviations also the terms used in 
the A-calculus (except that our terms for functions should specify the domains 
of these functions, which should be sets). Moreover: the reduction rules of the 
A-calculus are easy theorems of ZF+. To show this, we need another remarkable 
fact concerning ZF+, namely, that the use of definite articles is available in it: 

iXLp = {y I 3xip A '^x{ip ^ y G x)} 

(where y is a new variable, not occurring in (p). Here ixp (which is a valid term 
of ZF^ by clauses 6 and 2 in the definition of >~zf) intuitively denotes the 
intersection of all x such that p{x). In particular: if there exists a unique x such 
that p{x), then ixip denotes that x. Indeed, it can easily be proved® that 

\~ZF+ 3!x(/ 9 ^ Vx(<^ X = iXip) 

It should again be emphasized, however, that ixp is always meaningful, and 
denotes 0 if there is no set which satisfies cp, and the intersection of all the sets 
which satisfy p in case there is more than one such set^. 

Using ixp and the usual set-theoretical identification of a function with its 
graph we can now define A-abstraction and function application as follows: 

— Ax G s.t =Df {{Xjt) I X G s} (where x ^ Fv{s)). 

— ft =Df i-y-{t,y) G / (where y is new). 

— f/s=uf {(x, /x) I X G s} (where x is new). 

Identifying _L from domain theory with 0, we can easily check now that rules 
(3 and y obtain in ZF~^: 

— \~zF+ u G s ^ (Ax G s.t)u = t{u/x) (if u is free for x in t). 

“ ^ZF+ u ^ s ^ (Ax G s.t)u = 0 (if u is free for x in t). 

— \~ZF+ G s.tx = t/s (in case x ^ Fv{t)). 

For introducing other important notions concerning functions we need the 
following lemma: 

Lemma 1. There is a formula OP{z,x,y) in the basic language of ZF (i.e.: 
without abstraction terms) such that: 

1. Gzf+ OP{z,x,y) z = {x,y) 

2. OP{z,x,y) >ZF {x,y}. 

Proof: Such a formula was given in fact in the proof of Theorem 2. We re- 

peat the argument: Let Pa{z,x,y) =dj x G z A y G z A \/w{w G z ^ w = xV 



° Note that the extensionality axioms have a crucial role in this proof. 

Note that P|t as it was defined above is just ix.x G t, and indeed P|t denotes the 
single element of the set denoted by t in case t denotes a singleton. 
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w = y). Then Pa{z,x,y) >~zf {x,y}, and I"zf+ Pa{z,x,y) ^ z = {x,y}. Let 
OP{z, X, y) be the formula 3v3v{Pa{z, u, v) A Pa{u, x, x) A Pa{v, x, y). 

We can now define: 

1. Dom{f) =Df {x I 3z3y{z G / A OP{z, x, y)} 

2. Ran{f) =of {y \ 3z3x(z G / A OP{z, x, y)} 

4.3 Closure of ZPP Under Extensions by Definitions 

As we noted in the introduction, in mathematical practice new symbols for rela- 
tions and functions are regularly introduced in the course of developing a theory. 
This practice is formally based on the “extensions by definitions” procedure (see 
e.g. [7]). Now while new relation symbols are introduced just as abbreviations 
for (usually) longer formulas, new function symbols are introduced in a dynamic 
way: once Vyi, . . . , yn3!x(p is proved (where Fv{ip) = {yi, . . . ,yn, a;}) then a new 
n-ary function symbol can conservatively be introduced, together with a new 
axiom: Vj/i, . . . , j/„((^{E^(t/i, . . . ,yn)/x}). Now a particularly remarkable prop- 
erty of ZF^ is that this dynamic procedure is not needed for it. The required 
terms are available in advance, and every new function symbol we might wish 
to use may be introduced as an abbreviation for an already existing term. 

Theorem 4. For any formula ip of ZF~^ such that Fv{p) = {y\, . . . ,yn, x}), 
there exists a term t^ of ZF~^ such that Fv{t^p) = {y \, . . . , j/„}, and 

l"ZF+ Vj/l, . . . , yn^'-xp ^ Vyi, . . . , yn{p{t^/x)) 

Proof: Obviously, Lxp is a term t^p as required. 

An important corollary of the last theorem is that any set which has an 
implicit definition in ZF~^ has an explicit definition there, using an abstraction 
term. In other words: ZF~^ provides concrete term for every instance of the 
(unrestricted) comprehension schema which is provable in it: 

Corollary 1. Suppose \~zf+ ^Z\/x{x G Z p). Then there is a term tcp of 
ZF~^ such that Fv{tip) = Fv{p) — {a;} and \~zf+ Vx(a; G tcp p). 

Proof: This follows from the last theorem and the extensionality axioms. 



5 Transitive Closure and Peano’s Axioms 

With the exception of what we call here Peano’s Axioms (our version of the 
official infinity axiom of ZF), all the other axioms of ZF~^ are valid in the domain 
of hereditarily finite sets. In [2] we have suggested that languages and logics with 
transitive closure operation TC are the best framework for the formalization of 
mathematics. We show there how the special axioms for oj become redundant in 
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such a language. Instead, all is needed is to add a clause concerning TC to the 
definition of >~zf- For completeness, we repeat the needed changes (with some 
improvements) here®. 

THE SYSTEM 

The Language: The language of ZF^q is defined like that of ZF^ , with the 
following three changes: 

1. The constant ui is removed from the language (and removing of the 
constant 0 is possible too). 

2. The definition of the class of formulas should be supplemented with the 
clause that if (/? is a formula, and x and y are distinct variables, then 

s) is a formula. The intended meaning of this formula is the 
infinitary disjunction of the following formulas: 

ip{t,s),3wi{(p{t,wi)A(p{wi,s)),3wi3w2{(p{t,wi)Aip{wi,W2)/\‘p{w2,s)),. . . 

3. The definition of the safety relation >~zf should be supplemented with 
the following clause: 

- li if )~ZF X, and {x, j/} n Y yf 0, then [TCx,y^p) {x, y) >-zf Y.® 

Logic: This should be an appropriate extension of first-order logic with rules for 
TC (one of which should be a general induction principle - see [2]). The exact 
logic necessary to get a system equivalent to ZF has not been determined 
yet. 

Axioms: Exactly like ZE+, except for Peano’s axioms (which are simply deleted). 
Note that now the comprehension schema has more instances. 

Theorem 5. The set lo of the finite ordinals is definable by a term of ZFi^Q. 
Proof w = {a; I X = 0 V 3y{y = 0 A [TC^^y{x = {z|z = yVzG y})){x,y))} 

Note. 0 itself may be defined already in ZE+ as Ly.y = y. In other words: 

0 =DF {x I {3y{y = y) A 'iy{y = y ^ x & y)} 

Indeed, since it can be proved in ZF~^ that there is more than one set in 
the universe of sets, ty.y = y denotes the intersection of all the sets (see the 
discussion above concerning the l operator) . This intersection is of course empty 
(a fact that can easily be proved in ZF+). 

6 Conclusion 

Set abstractions of the form {x \ ip} are commonly used in mathematical practice. 
It is therefore very desirable that a practical formalization of Zermelo-Fraenkel 



® [2] includes also a short description of ZF~^ , without any details or proofs. 

® It is possible to provide a general clause determining when (TCx,y‘f){t, s) >~zf X, 
but the details are somewhat complicated, and we omit them here. 
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set theory ZF includes such terms. Since not all set abstractions are meaningful 
in ZF, indiscriminately allowing set abstraction terms in ZF would introduce 
terms into ZF that are actually undefined, and so before a term could be used its 
being defined would have to be proved. This problem is overcome in this paper by 
proposing ZF~^ , a conservative extension oi ZF which contains a large collection 
of set abstraction terms of the form {x | ip}. Given x and ip, {x | i^} is a member 
of this collection provided x and p satisfy a constructive syntactic condition, 
which we characterize by using an effective “safety” relation between formulas 
and (finite sets of) variables. We show that the use of these abstraction terms 
eliminate the need for the various comprehension axioms oi ZF (analogously 
to how function abstraction terms of Church’s type theory eliminate the need 
for comprehension axioms in simple type theory). We also show that all the 
standard notations employed in books and papers for sets, functions, operations 
etc. can easily be implemented in our formalization as simple abbreviations. 

ZF~^ is a compact, natural formalization of ZF which directly reflects usual 
mathematical practice. Accordingly, it can serve as a very useful and convenient 
base for designing and implementing automated provers and proof-checker for 
set theory. 
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Abstract. The Mizar system is equipped with a very large library con- 
taining tens of thousands of theorems and thousands of definitions, which 
often use overloaded notation. For efficient authoring of new Mizar ar- 
ticles it is necessary to have good tools for searching and browsing this 
library. It would be ideal if such tools were simple, intuitive and easy 
to access. Particularly, they should provide interactive and integrated 
support during authoring Mizar articles. 

We describe an approach to this task which uses the extendable MML 
Query tools to generate a special representation of the Mizar library 
(MML). This representation, so called Generated Mizar Abstracts, con- 
tains human readable form of the MML, completed by additional infor- 
mation which is missing or hidden in regular Mizar abstracts and texts. It 
also includes semantic information necessary for implementing advanced 
browsing in the Mizar authoring environment for Emacs (Mizar mode). 
Together with other functions of the Mizar mode, this allows the au- 
thors of Mizar articles to disambiguate the meaning of overloaded Mizar 
notations, and thus helps to start browsing at an appropriate place. 



1 Motivation and Previous Work 

1.1 Motivation 

The goal of the Mizar project ([10], [11], [8]) is to formalize and check by com- 
puter as much mathematics as possible. This is to be achieved by writing Mizar 
articles; such an article usually formalizes a (small) part of some mathematical 
theory. These articles are then included into the Mizar Mathematical Library 
(MML). The stored theorems, definitions, and other Mizar constructs are later 
referred to when writing new Mizar articles. 

The MML now consists of nearly 850 formalized articles, containing some 
37000 theorems and 7000 definitions. The Mizar language has been designed (by 
A. Trybulec) to be easy for both reading and writing even with such high number 
of concepts. To achieve this end, the language supports overloading of symbols 
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which comes in two flavors. The first, the so called ad hoc overloading, allows 
the same symbol to have several completely unrelated meanings. The second 
is polymorphism at the level of type hierarchy (e.g. the so called parametric 
polymorphism - one functor can have different result types for different types of 
arguments). Such features are not specific to Mizar, they have been found useful 
e.g. in many modern programming languages (C++, Java, ML, etc.). 

This language structure now causes that it is necessary to use Mizar-based 
tools (e.g. Mizar-like parser) when we want to disambiguate the exact meanings 
of symbols in some Mizar text. Using simpler browsing tools, like e.g. the stan- 
dard tag-based browsing which is widely used for non-overloaded programming 
languages, can be useful, but cannot generally achieve the required precision. 
The goal of our work reported here was to provide such precise browsing for 
the MML library, and to integrate it into the Emacs authoring environment for 
Mizar [12], so that a functionality similar to that of advanced Integrated Devel- 
opment Environments (IDEs) for modern overloaded programming languages is 
achieved. 

1.2 Previous and Related Work 

There are several projects related to ours. The oldest of them is the Journal of 
Formalized Mathematics (JEM) [7], which is the electronic counterpart of the 
Formalized Mathematics (EM), published by the University of Bialystok. JEM 
contains HTML-ized abstracts of the Mizar articles, which means that the sym- 
bols used in the formulas are linked to their definitions. JEM has been for long 
time the only tool of this kind, it is very useful even today, and at the moment it 
is the only “conservative” linked presentation of the Mizar abstracts, i.e. it just 
adds the HTML links, but does not change the text form of the Mizar abstract 
in any way. The main problem of the JEM is its technical implementation. It 
has been written with a large duplication of code, and given the fast develop- 
ment of Mizar, it is now outdated and very hard to maintain, to say nothing 
about adding new features (e.g. export of complete articles and linking of refer- 
ences). There are known problems in the JEM (e.g. bad browsing of selectors) 
that have not been repaired for some time. Our opinion is that JEM should be 
completely rewritten, based on a common XML-ization of the Mizar codebase 
and Mizar processing, and possibly merged with the functionality provided by 
the new MML Query tools [3]. 

The MML Query is another related project, and the work presented here is 
based on it. MML Query is a set of tools, which collects information about all 
Mizar items (e.g. symbols, constructors, theorems, definitions, etc.) from Mizar 
articles, and uses a database-like technology to store them, index them, and an- 
swer interactive queries about them. MML Query is not yet capable of presenting 
the Mizar abstracts in the same “conservative” way as the JEM can, since its 
first goal was mainly to capture the semantic content of Mizar articles. On the 
other hand it is much more flexible, and allows e.g. to recover the implicit parts 
of Mizar articles, like the definitional theorems or property formulas generated 
by Mizar automatically. The most common use of MML Query is via its HTML 
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interface, however it has also standard command-line interface, and other out- 
put formats are easily added. We use this possibility and define a simple output 
format easily parsable by Emacs for the work presented here. 

Finally, we can mention the earlier browsing features available in the Emacs 
authoring environment for Mizar. This includes tag-based browsing of MML ref- 
erences (i.e. theorems, definitions and schemes), which is sufficient and works 
well, because no overloading of their names is allowed in Mizar and every MML 
reference is unique. Similar tag-based functionality is also implemented for Mizar 
symbols (i.e. symbols for functors, predicates, etc.), however as mentioned ear- 
lier, this cannot provide the required browsing precision in the presence of 
overloading. 

2 Availability and Installation 

The complete system described in this article is for MML version 4.05.838 and 
it is about 5 MB big and unpacks to 64 MB. It is available on the web^, but we 
hope that eventually this will become a standard part of the Mizar distribution. 

This distribution should be directly unpacked into the directory $MIZFILES, 
set by the Mizar installation. The Emacs functionality is part of the Mizar mode 
for Emacs, which is a standard part of the Mizar distribution. Figure 1 is a 
screen-shot of the system in action, which can be also viewed on the web^. 

3 Implementation 

3.1 Design and Overview of the Implementation 

At the heart of our implementation is the notion of the Mizar Item (see the next 
section) defined by MML Query. This is a naming scheme uniquely identifying all 
Mizar symbols, constructors, theorems, etc. This naming scheme is the common 
semantic layer between MML Query and the browsing functions implemented 
in Emacs, and is also compatible with the naming schemes used in other Mizar 
related projects like MPTP [14] or MoMM [13]. 

Our implementation consists of the following parts: 

— The customized MML Query tools (output filters) used for producing the 
Generated Mizar Abstracts from MML. 

— The Generated Mizar Abstracts, containing a simple and easy-to-parse 
Emacs-based mark-up used for locating the Mizar items in them. 

— The Emacs parsing and presentation of the Generated Mizar Abstracts, and 
browsing of the Mizar items in them. 

~ Additional Emacs support for disambiguating parts of the article currently 
developed by the author into the Mizar items, which allows immediate pre- 
cise browsing. 



^ http : / /merak.pb .bialy stok.pl/gab/gab- 4 . 05 . 838 .tar . gz . 
^ http : / /ktiml .mf f . cuni . cz/~urban/ snapshots .png. 





Fig. 1. Generated Mizar Abstract for article CARD_FIL in the Emacs browser 

3.2 Mizar Items 

For a basic overview about available Mizar items defined by the MML Query, 
it is best to have a look at their HTML-ized grammar, available at [6]. Mizar 
items are uniquely identified by their kind, their Article-name and their Serial- 
number in their article. There are many kinds of Mizar items, they can be 
logically divided into Constructor-kinds, Notation-kinds, Registration-kinds and 
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Statement-kinds. Their meaning is probably best explained on an example from 
the MML. 

Consider the Mizar definition of the attribute cardinal - the first definition 
in the article CARD_1 [1]: 

definition let IT be set; 
attr IT is cardinal means 
:: CARD_l:def 1 

ex B St IT = B & for A st A,B are_equipotent holds B c= A; 
end; 

This definition produces several Mizar items. First of all a Constructor item 
CARD_1 : attr 1 is created. This item denotes the unique Mizar attribute defined 
here, with its firm semantics given by this definition. This definition is also used 
to create a Statement item CARD_1 : def 1. This is a definitional theorem created 
automatically by Mizar for this attribute: 

theorem 

for IT being set holds IT is cardinal 
iff 

ex B being ordinal set st 

(IT = B & for A being ordinal set 
st A,B are_equipotent 
holds B c= A) ; 

The definitional theorem CARD_1 : def 1 can be explicitly quoted in Mizar 
proofs. Some Mizar definitions can be also used as macros, that work auto- 
matically and do not have to (and cannot) be explicitly quoted. Such macros 
(called definientia in Mizar) are another kind of Statement items, its name here 
is CARD_1 :dfs 1, and its meaning is expressed as follows: 

def iniens 

let A1 be set; 

To prove 

A1 is cardinal 
it is sufficient to prove 

thus ex B1 being ordinal set st 
(A1 = B1 & 

for B2 being ordinal set 

st B2,B1 are_equipotent 
holds B1 c= B2) ; ; 

Mizar allows the authors to provide arbitrary notation for the constructors 
(whose role is to specify the semantics). The binding of a particular name (and ar- 
ity) to a constructor is captured by Notation items. Here it is CARD_1 : attrnot 1 
which binds the attribute symbol cardinal applied to one argument of the type 
set to the Constructor item CARD_l:attr 1. The Notation items provide the 
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main method for dealing with different notations in different parts of mathemat- 
ics, without influencing the semantic layer. 

To sum up, the first definition in the article CARD_1 produces four Mizar 
items: 

— the constructor CARD_1 : attr 1 

— the quotable definitional theorem CARD_l:def 1 

— the unquotable definiens CARD_1 : df s 1 

— the notation CARD_1 : attrnot 1 

One additional fact about the handling of the Mizar items in MML Query 
should be noted here. All terms and formulas appearing in them are disam- 
biguated into the semantic (constructors) form. That means that e.g. for the 
above given definitional theorem CARD_l:def 1 we know for each symbol ap- 
pearing there the constructor to which it actually refers. Actually, in the current 
version of MML Query only the constructor form is known precisely, and the 
human presentation is reconstructed from it, using the knowledge about the 
Notation items available at a given place. Since there is often more than one 
way how to do this (e.g. when multiple synonyms are available), this can cause 
that the reconstructed human presentation sometimes slightly differs from the 
original in the article. 



3.3 The Generated Mizar Abstracts 

Many of the Mizar items are never written explicitly in the original article. E.g. 
the definitional theorems can have quite complicated form, when a definition 
with several cases (so called Conditional- Definiens) is used. This sometimes 
causes problems to the Mizar authors, who need to know the exact form of 
such theorems, to be able to use them in proofs. 

The purpose of the Generated Mizar Abstracts is to provide human readable 
presentation of various Mizar items, in a format similar to that of the original 
abstracts. We also want to allow browsing of various automatically created items 
(e.g. definitional theorems), which are not explicitly written in the normal Mizar 
abstracts. 

Given these requirements, the structure of the current version of the Gener- 
ated Mizar Abstracts (GABs) is following: 

— Every GAB corresponds to exactly one normal Mizar abstract, and it con- 
sists of all Mizar items defined in the original abstract in the same order of 
appearance. 

— Particularly, the parts of normal abstracts that are not Mizar items are not 
present in GABs. This means that e.g. comments, reservations or pragmas 
like canceled do not appear here. All variables in all items are fully qualified, 
while in the original abstracts, it is often necessary to search the reservations 
for their types. 
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~ The items which are not explicitly written in the original abstract are by 
default hidden, and only their names are visible, so that the default GAB 
looked as close as possible to the original abstract. The presentation ob- 
viously implements functions for easy changing and customization of the 
visibility of items. 

— Most importantly, all symbols inside terms and formulas presented in GABs 
are disambiguated and tagged with the appropriate constructor, which allows 
precise browsing. 

Figure 2 is an example of the initial part of the file card_l .gab corresponding 
to the Mizar abstract card_l.abs [1]. 

3.4 Encoding of the Generated Mizar Abstracts 

For encoding of the additional browsing information in GABs we have used a 
modified version of the text/enriched MIME Gontent-type [9,5,4], which we 
currently call text/mmlquery. This format is quite light-weight in comparison 
with formats like HTML or XML, and it is completely sufficient for our purpose. 
The generally implemented standard Emacs parser of the text/enriched format 
can be easily customized for the text/mmlquery format. 

Following explanation of the text/mmlquery format is a paraphrase of the 
text/enriched syntax explanation from [9]: 

The syntax of ’’text/mmlquery” is very simple. All characters represent them- 
selves, with the exception of the ”<” character (ASCII 60), which is used to 
mark the beginning of an annotation. A literal less-than sign (”<”) can be rep- 
resented by a sequence of two such characters, ”<<”. Annotation instructions 
consist of annotating commands surrounded by angle brackets (”<>”, ASCII 
60 and 62). Each annotating command may be no more than 60 characters 
in length, all in US- ASCII, restricted to the alphanumeric and hyphen (”— ”) 
characters. Annotating commands may be preceded by a solidus (” /” , ASCII 
47), making them negations, and such negations must always exist to balance 
the initial opening commands. 

The current version of the text/mmlquery format currently uses just the 
following annotation commands: 



< p > ... < /p > 


Is used to encode arbitrary parameters to other annotation com- 
mands. i.e. it corresponds to the < param > command of the 
text /enriched format. 


<l > ... < /I > 


Is used to mark the whole Mizar items in GABs, the name of 
the item is given as a parameter. 


< a > ... < /a > 


Is used inside terms and formulas to provide the link from the 
symbols to the corresponding Mizar items (which are given as a 
parameter). 


< r > ... < /r > 


Is used to mark the Mizar property formulas inside definitions 
(they are hidden by default). 


<h> ... < /h> 


Is used to mark parts that we explicitly want to hide. This is 
now becoming obsolete, since all hiding of the Mizar items is 
now done depending on their kind. 
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:: Article CARD_1 , MML version 4.05.838 

: : CARD_l:attrnot 1 

definition 

let Al be set ; 
attr Al is cardinal means 
ex Bl being ordinal set st 

(Al = Bl & for B2 being ordinal set 
St B2,B1 are ecruipotent 
holds Bl c^ B2 ) ; 

end; 

: : CARD_l:dfs 1 
def iniens 

let Al be set ; 

To prove 

Al is cardinal 
it is sufficient to prove 

thus ex Bl being ordinal set st 

(Al = Bl & for B2 being ordinal set 
st B2 , Bl are ecruipotent 
holds Bl c~ B2 ) ; ; 

: : CARD_l:def 1 
theorem 

for Bl being set holds 
Bl is cardinal 

iff 

ex B2 being ordinal set st 

(Bl = B2 & for B3 being ordinal set 
st B3,B2 are equipotent 
holds B2 c^ B3) ; 

: : CARD_1 : exreg 1 
registration 

cluster cardinal set ; 
end; 

: : CARD l:modenot 1 
definition 

mode Cardinal is cardinal set ; 
end; 

: : CARD 1 : condreg 1 
registration 

cluster cardinal -> epsilon- transitive epsi Ion- connected ordinal ( set ) ; 
end; 

: : CARD_l:th 4 
theorem 

for Bl being set holds 

ex B2 being ordinal set st 



B1,B2 are eguipotent ; 



: : CARD 


Irprednot 1 




notation 








let Al 


be 


cardinal 


set ; 


let A2 


be 


cardinal 


set ; 



synonym Al <= ' A2 for Al c^ A2 ; 
end; 



Fig. 2. Initial part of the Generated Mizar Abstract for article CARD_1 
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E.g. the first existential registration in the file card_l . gab (see CARD_1 : exreg 1 
in Fig. 1) encoded in text /mmlquery looks like this: 

<1> : : <p>CARD_l : exreg. K/p>CARD_l : exreg 1 
registration 

cluster <aXp>CARD_l : attr . K/p>cardinal</ a> <aXp>HIDDEN :mode . K/p>set</ a>; 
end; 

</l> 

The blow-up factor caused by adding the annotations into the GABs is about 
3 to 4. This is mainly caused by the long names of the Mizar items which 
disambiguate the Mizar symbols. We could compress the default naming scheme 
significantly, however as shown below in the subsection about Emacs parsing, 
the parsing speed is sufficient already now, and the overall size of all GABs is 
also reasonable - about 50 MB. 

3.5 Using MML Query to Produce the Generated Mizar Abstracts 

MML Query is a set of tools which collect information about all Mizar items (e.g. 
symbols, constructors, theorems, definitions, etc.) from the Mizar Mathematical 
Library, and store them in a format which is easy to index and query. The 
Mizar-dependent part of MML Query is based on the Mizar codebase written in 
object Pascal; the remaining parts are mostly written in Perl. The Perl modules 
implement functions like reconstruction of the human readable form of Mizar 
items from the internal representation, or parsing and execution of the queries 
written in the MML Query syntax [2]. They also implement a general plug- 
in mechanism for different presentations of the Mizar items and results of the 
queries. 

For the work presented here, we have implemented a special plug-in which 
customizes these general presentation mechanisms to the text /mmlquery format. 
This is done very simply in as few as about 50 lines of Perl code. The complete 
creation of the Generated Mizar Abstracts from the MML Query database takes 
about 17 minutes on Intel Pentium 4 3GHz. MML Query is also used to generate 
the “raw” counterparts of the Generated Mizar Abstracts, which contain no 
markup and are thus suitable for processing with standard text tools like e.g. 
grep. The current usage of these files in our system is described in the next 
section. 



3.6 Emacs Parsing, Presentation and Browsing of the Generated 
Mizar Abstracts 

As already mentioned, the Emacs parser of the text /mmlquery format is just a 
customization of the unified Emacs mechanism for formatted files, which is also 
used for the text/enriched format. This customization is quite simple and takes 
only about 200 lines of the Emacs Lisp code. The parser uses the annotations 
from a given GAB and produces internal information necessary for presentation 
and browsing. This information is internally represented in two ways: 




Integrated Semantic Browsing of MML 



53 



~ The positions of Mizar items parsed from a given article are kept as symbol 
properties in the standard Emacs symbol hash-table. 

— The links associated to the Mizar symbols and visibility information are kept 
as Emacs text properties. 

Thanks to the simplicity of the text/mmlquery format, the parsing of GABs 
is sufficiently fast, even though Emacs Lisp is an interpreted language which is 
not primarily designed for speed. Complete parsing of an average GAB takes 
about 1-2 seconds on quite a standard computer (Intel 1.6 GHz), the largest 
Mizar abstract JGRAPHM (about 300 KB with annotations) takes about 7 
seconds. These times can be further reduced to less than half by byte-compiling 
the Emacs Lisp code. For a comparison, note that displaying the HTML version 
of the GAB of JGRAPH_4 (also produced by MML Query) by the standard 
Emacs/W3 web browser takes about 40 seconds on the same computer, even 
though it is only about 100 KB bigger. 

The Emacs presentation of the Generated Mizar Abstracts reuses many com- 
ponents which are available for normal Mizar abstracts and articles in the Emacs 
authoring environment for Mizar. This includes e.g. the syntax highlighting, in- 
teractive menu and speed-bar for items presented in the abstract, etc. Actually, 
a special submode (MML Query minor mode) of the standard Mizar mode is 
used for the presentation of GABs. This submode just adds or redefines the 
functionality, which is needed for proper presentation and browsing of GABs. 
This now includes the standard browsing functions like following links, and go- 
ing backwards and forwards in the link history or presentation functionality like 
tool-tips or setting and customization of visibility of various items. 

For fast grepping, we generate for each GAB its “raw” counterpart which 
contains no markup. The grep results are then presented in Emacs as if the 
grepping was done on the original GAB, the “raw” GABs are completely hidden 
from the user. This solves the usual problem with grepping annotated formats, 
without the necessity of using any specialized grepping tools or tools for strip- 
ping the markup (like perl), and is also faster then them, while the additional 
installation size (about 16 MB) is negligible. If perl is installed, the “raw” GABs 
also allow for regular expression searches spanning multiple lines in items, which 
is often useful in Mizar. Such features however already duplicate some of the 
functionality of the MML Query tools, therefore our further work in progress is 
a full integration of the MML Query tools into the Mizar mode as a backend for 
advanced queries. 

3.7 Support for Authoring Mizar Articles 

We believe that the described above features of our system make it evident, 
that having a GAB browser inside Emacs is a good choice, allowing reuse or 
customization of the vast number of available Emacs components, with very 
little effort and very reasonable resource requirements. This allows easy local 
installation and usage by an average Mizar user. 

Another important feature of this system is, that it allows us to support 
interactive browsing even for the article which is being written by the author 
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at the moment. This is very helpful when writing Mizar articles in advanced 
domains, where clashes of notation are quite often, and the author needs a good 
tool telling him how the formulas written by him are understood by the system. 

Implementation of this feature uses parts of the Mizar system (parser and 
analyzer) to obtain the disambiguated (constructor) format of the formulas writ- 
ten by the author. Note that Mizar is not an interactive interpreter like some 
other proof assistants, its behavior is much more like a batch compiler. In this 
article we do not want to discuss the advantages and disadvantages of these 
different paradigms for proof assistants, nevertheless our implementation shows 
that even with the compiler-like approach, a fairly interactive disambiguation 
is not difficult to achieve (which again is also testified by the large number of 
Integrated Development Environments for compiled overloaded languages, with 
similar functionality) . 

We take advantage of the fact that different processing stages of the Mizar 
verifier use intermediate files for passing information to the next stages. The 
intermediate files usually contain also information about positions in the original 
article, so that proper error messaging was possible. Thus, for our purpose it 
suffices to collect the disambiguated (constructor) format from the appropriate 
intermediate file, and associate it with the corresponding position in the original 
article. This association is done using the Emacs mechanism of text properties 
immediately after processing, which means that even the editing actions that 
change positions will usually not influence the correspondence between the text 
in the article and its disambiguated counterpart. 

In the Emacs authoring environment for Mizar this mechanism is called the 
Constructor Explanations, and when switched on by the user, a disambiguated 
form compatible with that used by GABs is available after Mizar processing 
for any formula in the article justified by simple justification. This is no serious 
limitation, and it will be probably completely removed after the XML-zation of 
the intermediate files, which is a planned feature of the Mizar system. This GAB- 
compatible disambiguated form of the formulas can then be used for immediate 
precise browsing of the symbols appearing in them, provided that the user has 
installed the Generated Mizar Abstracts. 

4 Example 

Finally we demonstrate our system on a simple real-life example. Gonsider the 

following simple Mizar article: 

environ 

vocabulary ARYTM, NAT_1, XREAL_0; 

notation SUBSET_1, NUMBERS, XCMPLX_0, XREAL_0, REAL_1, NAT_1; 
constructors REAL_1, XREAL_0, XCMPLX_0, XB00LE_0, NAT_1; 
clusters REAL_1, NUMBERS, XREAL_0, ZFM1SC_1, XB00LE_0 , NAT_1; 
requirements REAL, NUMERALS, SUBSET, BOOLE, ARITHM; 
begin 

LI: for X being Nat holds x*x <= (x + x)*x; 
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Suppose that the user wants to know the exact meaning of the symbols in 
the formula LI. Simple grepping or tag-based browsing of the MML reveals that 
there are 

— 164 definitions or redefinitions of the symbol * 

— 99 definitions or redefinitions of the symbol -I- 

— 16 definitions or redefinitions of the symbol <= 

Instead of searching this number of possibilities, the user just switches on the 
menu item Constr. Explanations -> Verbosity -> translated formula in the Mizar 
mode for Emacs, and after running Mizar the following disambiguation of LI 
can be obtained by clicking on the final semicolon: 

for SUBSET_l:mode.2 ; ORDIHALl : attr . 1 ; ORDIHALl : attr . 2 ; ORDINAL 1 : attr . 3 
; 0RDIHAL2:attr.4 ; XCMPLX_0 : attr . 1 ; XREAL_0 : attr . 1 ; ; NUMBERS : func . 1 ; 
NUMBERS : f unc . 5 ; ; XREAL_0 : pred . 1 NAT_1 : func . 2 B1 B1 ; NAT_1 : func . 2 
NAT_1 : func . 1 B1 B1 ;B1 ;; 

The underlined items are directly browsable, and e.g. clicking on the last 
item NAT_1 : func . 1 starts browsing of the GAB of the article NAT_1, and goes 
to the appropriate definition: 

:: NAT_1 : funcnot 1 
definition 

let A1 be Element of NAT ; 
let A2 be Element of NAT ; 
redefine func A1 + A2 -> Element of NAT ; 
coimnutativitY ; 
end; 



The underlined items can be further explored, which loads and browses the 
appropriate GABs at appropriate places. Since this is a redefinition, even the 
symbol + is linked to the constructor it redefines, i.e. XCMPLX_0 : func 2. Glicking 
on the commutativity keyword displays the meaning of this property, which is 
following: 

for Al, A2 being Element of NAT holds 
A1 + A2 = A2 + Al; 



5 Summary 

We have presented an integrated environment for semantic browsing of the Mizar 
abstracts and articles being written in the Mizar mode for Emacs. This environ- 
ment consists of the Generated Mizar Abstracts produced by the customization 
of the MML Query tools to the light-weight text/mmlquery format, Emacs pre- 
sentation and browsing of these abstracts based on many reusable components 
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of Emacs and its Mizar mode, and of functions for disambiguating the currently 
authored Mizar article, based on the information obtained from the Mizar veri- 
fier. This solves the problem of finding out the exact meaning of the overloaded 
mathematical notation used practically everywhere in Mizar, which is becom- 
ing more severe as more and more advanced mathematical articles combining 
different parts of mathematics are written. Our implementation reuses many 
components of other systems, and thus it is quite small and easy to maintain. 
Even though the MML is the world’s largest collection of formalized mathemat- 
ics, the resources required by our system are modest and it is accessible to any 
Mizar user as a simple and stand-alone local installation, without the necessity 
for installing any other specialized tools. 



6 Future Work 

As already mentioned, adding MML Query as a back-end for interactive queries 
is currently a work in progress. This means that answers to queries will be 
presented in the text/mmlquery format and immediately decoded by Emacs in 
the same way as the Generated Mizar Abstracts. 

It would be nice to have features like presentation of whole Mizar articles (i.e. 
also with proofs, not just abstracts), however this is rather a general todo-item 
for MML Query, of which the Generated Mizar Abstracts are just a suitable 
presentation. Both MML Query and e.g. the Constructor Explanations mech- 
anism in the Mizar mode for Emacs could be simplified and easily extended if 
the internal Mizar database and the intermediate processing files were using a 
simple XML format instead of the current fragile and illegible internal encoding. 
We believe that it is really high time for XML-ization of these parts of Mizar, 
even at the cost of temporary postponing of other works on the Mizar system. 
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Abstract. Finding required information in a library of mathematics can 
be problematic, just as in any other library. However, so far, there are no 
strong search methods based on the semantics of formal mathematics. 
This paper describes a new approach based on latent semantic indexing 
(LSI). Using this, the semantics of terms need not be explicitly defined 
but is indirectly inferred from a body of documents in which the terms 
occur. The Mizar library is used as it is a substantial resonrce of formal 
mathematics. The system described in the paper adapts Mizar articles 
to produce an appropriate body of documents that can be used by LSI. 
Preliminary tests suggest that this approach is able to provide a useful 
mechanism for the search and retrieval of formal mathematics. 



1 Searching for Mathematics 

Mathematical knowledge management, since its inception, has had two key 
themes: the organisation of mathematical knowledge; and the successful retrieval 
of mathematical knowledge. In this paper, we consider the retrieval task when the 
mathematical knowledge has already been organised and standardised, namely 
retrieving knowledge from the Mizar Mathematical Library (MML) [20]. 

Bancerek and Rudnicki [2] have already considered information retrieval in 
the MML. Their approach rightly criticised the poor quality of keyword and 
grep-based approaches. However, they do have a hypertext method of presenta- 
tion that allows a person to browse the library and easily find definitions of terms 
by clicking on the appropriate terms in the presentation. Additionally, they de- 
veloped a query language that allowed more sophisticated querying based on the 
structural and semantic properties of Mizar articles. This was recognised as only 
a first step towards full semantic search and as such may only be useful in this 
form to expert Mizar authors. 

Other search techniques have used type isomorphisms [9], metadata [17] or 
a combination of metadata and reasoning [5]. With type isomorphisms or rea- 
soning, the search engine is effectively doing some proving, albeit tailored to the 
particular task. As fully automated proving is still a significant research topic, 
this suggests that there is a limit to how far these approaches could extend. With 
metadata, there is of course the possibility to make a search engine very effective 
but then there is the overhead of who must prepare the metadata. Authors of 
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webpages are already very poor at adding metadata and there is no suggestion 
that authors of mathematics are likely to be any better. 

Latent semantic indexing avoids these issues entirely as the semantics of the 
documents to which it is applied are never explictly represented. Instead, the 
semantics of terms are implicitly inferred from contexts in which they occur 
even if, as in the case of mathematics, the contexts are sometimes the definitions 
of the terms. 

Related to this is the notion that mathematics itself is not a formal language. 
Mathematics is in principle formalisable but, in practice, formalisation is hardly 
ever done (which is why the MML represents a valuable contribution to math- 
ematics). I would argue that mathematics, like all human languages, functions 
at a level of discourse [21] rather than at a level of logic. Search that works at 
the level of mathematical discourse is more likely to fit better with the needs of 
working mathemticians. 

This paper therefore treats formal mathematics as a representation of math- 
ematical language in general. Mizar is particularly strong in providing a wide 
range of constructs for mathematical concepts [24] that allow its formal proofs to 
be more like the less formal proofs found in common mathematical texts. In this 
sense, the MML is actually a reliable representation of the more usual, informal 
mathematical language. A well-known, and indeed successful, technique in in- 
formation retrieval is Latent Semantic Indexing (LSI) [6]. Rather than defining 
semantics through some explicit ontology, the semantics of terms are defined 
through their co-occurence in a large document set. This is discussed in detail 
in the next section but the main point is that the semantics of terms are latent 
in the substantial body of documents to which LSI is applied. The MML is able 
to provide exactly such a large set of documents from which semantics can be 
extracted. 

After describing the details of applying LSI to the MML, I give some early 
results. Despite the counter-intuitive idea of ignoring the formal semantics in- 
herent in formal mathematics, these results actually show some promising in- 
dications. The current implementation does not make full use of the MML for 
reasons discussed elsewhere [8] and so there are natural areas for further work 
and refinement of these results. 



2 Latent Semantic Indexing 

Latent semantic indexing is a method developed for doing information retrieval 
from natural language documents based on the general theory of latent seman- 
tic analysis (LSA) [15]. LSA has been used in a variety of text retrieval and 
analysis tasks including the various Text Retrieval Conferences (TREC) [23] 
competitions, selecting educational text and the automated assessment of essays 
[16]. 

The major task of any information retrieval system of this sort is to define the 
semantics of the documents and the terms in those documents. The semantics can 
then be used to reliably answer queries based on the documents. For example. 
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a person seeking information using a query “wars in the Middle East” would 
probably be satisfied with a document about “conflicts in Iraq.” This is because 
we recognise that “conflict” is a synonym for “war” and “Iraq” is in the “Middle 
East” . Many text retrieval systems rely on some externally defined ontology that 
would make the semantic relationships between terms explicit. Thus, when given 
the example query the meaning of the query would be looked up and documents 
with a similar meaning would be returned. 

With LSI, there is no such external ontology. Instead, the meaning of terms 
is held to be latent in the documents in which those terms appear. That is, a 
word gains its meaning from the many contexts in which it appears. Conversely, 
a document gains its meaning from the many words that occur within it. Clearly 
then for LSI to produce good semantics, it needs a substantial body of docu- 
ments in which all the relevant terms occur in many and varied contexts. The 
advantage is that no work needs to be done to define an ontology for querying 
the documents. 

For this reason, LSI seemed an appropriate tool to use and the MML the 
appropriate context in which to use it. Formal mathematics, in one sense, is 
an entire ontology of mathematical terms. However, as yet, it has not been ex- 
tensively used to provide effective information retrieval. Through LSI though, 
the MML also represents an extensive set of documents that latently define the 
meanings of a huge number of mathematical terms. In addition, the ric language 
of Mizar reflects some of the richness of more traditional, human-oriented math- 
ematics. LSI could tap into this to provide an alternative ontology without any 
extra work. 

The other advantage of LSI is that its mechanism relies on some elegant 
mathematics that has been implemented in the GTP package [10]. GTP is writ- 
ten in Java. The mathematics is briefly described here to give a flavour of how 
it works. Followed by some details of the implementation specific to GTP. 

2.1 The Mathematics of LSI 

The occurrence of terms in documents can be simply captured in a rectangular 
matrix A where : 

^ _ f 1 if the term appears in the j^^document 

\ 0 otherwise 

Keyword search can then be implemented by converting a query into row 
vector t where ti is 1 if the term is in the query and 0 otherwise. Taking 
d = t.A, d is row vector where dj is the number of query terms occurring 
in the document. In particular, if n is the number of non-zero entries in t 
(that is, the number of distinct terms in the query) then dj = n means that the 
document contains all of the query terms. 

Using singular value decomposition (SVD), it is possible to find two orthog- 
onal matrices U and V and a diagonal matrix Su such that: 



Z\ = USdV 
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From this equation, for a term vector t, keyword search would give: 



d = t.UEoV 
d.V~^ = t.UEo 

However, we require more than keyword search. Instead, for a given query t, 
and any set of documents represented by d we consider the similarity between 
the two vectors t' = t.USo and d' = d.V~^. The similarity, s, between vectors 
t' and d' is taken to be the cosine of the angle between them, that is: 

t'.d' 

""MW 

One way to view this is that, under the transformations given, terms and 
documents occupy a common space based on the semantics of the terms. Now 
to perform a query, the term vector t is generated as before. Each document is 
represented by the vector di where dij = 1 if i = j and 0 otherwise. The query is 
then compared to all the documents in the term/document space by finding the 
similarity between t' and each of the vectors d'^. The most similar documents 
are returned as the results of the query. 



2.2 The GTP Package 

Given a set of documents as either separate files or documents delimited within a 
single file, GTP automatically extracts terms from the documents and constructs 
A. By default, a term in GTP is any alphanumeric string of characters. Also, 
because GTP was constructed with natural language in mind, it consults a file 
of common words, such as “the” and “of” , and does not include a common word 
as a term. Mizar (like mathematics), however, has a radically different linguistic 
structure and punctuation from natural language. Instead, this section of GTP 
was replaced. Gommon words were simply Mizar keywords, though arguably 
they could be included as terms, together with and when used purely as 
separators. This means that terms could be any string of characters excluding 
whitespace and thus encompasses all of the constructs defined in Mizar articles. 

Having defined the terms, the GTP package automatically constructs the 
appropriate A and performs the singular value decompostion. This is the main 
output of the first stage of GTP. 

The querying process is run as a separate stage of GTP using the matrices 
generated from the first stage. As might be expected, the comparison process 
can be rather lengthy so there are some approximations that can be made to 
speed up matters. To facilitate discussion, in the sequel, the diagonal values of 
Ejj are referred to as the eigenvalues of A. 

The first approximation is to omit the scaling by the eigenvalues by taking 
t' = t.U. However, it produced uniformly poor results so this approximation 
was not used. Secondly, each eigenvalue corresponds to a factor that can be used 
to compare queries and documents. When the eigenvalues are very small, they 
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can effectively be omitted from the calculation and hence speed it up. In GTP, 
setting the number of factors to 15 corresponds to calculating similarity based 
on the fifteen largest eigenvalues. The number of factors used in the test was 
varied as will be discussed in the results section. 

In summary, to a large extent, LSI is treated here as a black box method for 
querying documents. The GTP implementation is untouched except to replace 
the code that identifies terms in the MML. 



3 Applying LSI to Mizar 

As most of the computational effort is done by GTP, the two main issues for 
applying LSI to Mizar are: 

1. What constitutes a document? 

2. How should queries be performed? 

All coding was done in Java 1.4 and the Java version of the GTP package 
was used. Version 3.33.722 of the MML was used to generate the documents. 
More specifically, rather than use the full Mizar articles with proofs, only the 
abstracts were used in this implementation. 

3.1 Making the MML into Documents 

The decision as to what constitutes a document is crucial because this is how LSI 
will capture the semantics of Mizar terms. At one level, each Mizar article could 
be considered to be a document. However, these are substantial pieces of work 
with many references to a large number of terms. It was felt that with many 
terms in each article and a reasonable overlap between articles, using articles 
as documents would not distinguish sufficiently between the meanings of terms. 
Also, when retrieving a document, a user would probably like something more 
focused than a whole Mizar article. The natural choice seemed to be to divide 
each article into smaller parts. These parts should be both meaningful as a stand- 
alone entity (so not single lines of proofs) and the kind of thing that users would 
like to retrieve. Accordingly, a document was decided to be one of the following: 

1. Theorem 

2. Definition 

3. Proof 

As parsing Mizar articles can be problematic [8] , the first stage seemed to be 
a proof of principle on using only theorems as documents and then only those 
that were in abstracts. 

Simply using a theorem statement directly from a Mizar abstract was also 
not likely to provide an appropriate document. For example, in the following 
theorem [3]: 

theorem : : 0RDINAL2 : 1 

A c= B iff succ A c= succ B; 
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A and B would be identified as terms but without a doubt they are also 
used as terms in a huge number of other theorems with considerably different 
meanings. This would greatly confuse the semantics of the library. Also, users 
are not likely to find theorems about A and B interesting, but rather theorems, 
like this one, about successors of Ordinals. 

In this case, A and B have already been defined as Ordinals in a reserve 
statement. A more meaningful document would be: 

theorem : : 0RD1NAL2 : 1 

for A, B being Ordinals holds A c= B iff succ A c= succ B; 

However, A and B still occur as terms in this document and could add noise to 
the LSI calculations. Instead, the document is made by replacing each occurrence 
of a variable by its type: 

theorem : : 0RDINAL2 : 1 

Ordinal c= Ordinal iff succ Ordinal c= succ Ordinal; 

Thus Ordinals, successors and subsets all occur in the same context which 
LSI would use to say that the meaning of Ordinals is somehow defined by that 
of succ and c=. In addition, this document contains only terms and keywords 
and these latter are currently ignored. 

Thus, each document is a theorem where all of the known variables have 
been replaced by their types. There is no further reduction of types to simpler 
types, for example, to say that Ordinal is an epsilon-trauisitive epsilon- 
connected set. This is because the aim is to look at the linguistic structure of 
the mathematics not the logical. 

The process for producing the documents is given in Figure 1 and works 
as follows. The header of each Mizar abstract is used to generate the vocabu- 
lary used in each abstract. This means that the abstract can be reliably parsed 
into chunks that are either theorems, reserve statements or definitions. The re- 
serve statements are parsed to produce of a list of variables that have a known 
type. The definitions are also parsed to check exactly which definition of vari- 
ous terms are actually in use at a given point in an article. As a by-product of 
parsing definitions, a catalogue is produced that states exactly where each item 
of vocabulary is defined together with any other useful information such as the 
number of pre- and post-arguments, where applicable. 

The catalogue and known variables provide a context for a particular the- 
orem. The theorem can be parsed using the context and transformed into the 
corresponding document as required. 

The process progresses through the chunks, successively updating the context 
as it goes. So for instance, if a reserve statement redefines a variable as having 
a new type, this is carried through to the subsequent theorems and hence doc- 
uments. 

On the whole, the process works well. There are still some abstracts that 
cannot be parsed into chunks because of the use of in the terms. However, 
this is largely due to the limitation of the current parsing technology being used. 
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Fig. 1. Generating documents from theorems in an abstract 



namely JavaCC [12]. It is hoped to replace this with a more versatile parser in 
the near future. The final document set is made up of 31251 documents that 
contain 3181 terms. GTP transforms this data and captures it in 106 factors, 
that is, 106 eigenvectors with non-zero eigenvalues, though it is not documented 
to what degree of accuracy GTP distinguishes a nearly zero eigenvalue from 
actually zero. 

3.2 Performing Queries 

If queries are to be useful to a user of the MML, the query engine most likely 
needs to be integrated into some larger system, such as the emacs mode for 
Mizar. However, at this stage, it is not clear what would constitute a useful 
query. This can be seen by considering the process that is done to convert a 
theorem in Mizar into a document for LSI. To what extent should the user 
do that conversion process to formulate a query? Or conversely, how much of 
formulating a query can be generated from a user’s context of querying? 

These are difficult questions in any system where complex work such as writ- 
ing Mizar articles is being performed [18]. This is compounded by the fact that 
the full capabilities of LSI-based search are unknown. 

Rather than commit at this early stage to a visual interface that may be both 
inappropriate and lengthy to develop, the system implemented uses a command- 
line approach to querying and all of the preparation of queries is done by hand. 

Thus, a query is hand-written or adapted from a document based on a theo- 
rem. For example, a typical query might look like: 
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theorem set c= set implies Cl ( set /\ set ) c= Cl ( set /\ set ) 

The results from the basic GTP are the indexes of documents in the whole 
collection together with the strength of similarity between the document and 
the query. For example, GTP might produce results like: 



4134 


0.99987674 


8609 


0.99812323 


8610 


0.99809912 


25838 


0.99731101 



The first number of each line corresponds to the index of a document. The 
second number is the strength of match with the query. The resulting documents 
are looked up in an index prepared at the same time as the documents were 
produced from the theorems. Thus, the basic results can be expanded to: 

: : theorem set c= set implies Cl ( set /\ set ) c= Cl ( set /\ set ) 



4134 


:: CLASSES1:68 


classesl 


322 


0.99 


8609 


: : FUNCT_4 : 6 


funct_4 40 


0.99 




8610 


: : FUNCT_4 : 7 


funct_4 43 


0.99 




25838 


:: T0LER_1:57 


toler_l 261 


0.99 





The first line is the original query expression. Each subsequent line is a 
matched document in order of best match. For example, the second line tells us 
that document 4134 matched best and it corresponds to the theorem with the 
Mizar label CLASSESl : 6 and it appears in the file classesl . abs [4] at line 322. 
The remaining three lines correspond to theorems in the articles f unct_4 . abs 
[7] and toler_l.abs [11]. 

These results are then turned into fragments of the corresponding abstracts to 
save time and effort of looking up each query result individually. So for instance, 
the result just described would also return the fragment: 

4134 :: CLASSES1:68 classesl 322 0.99 

theorem :: CLASSES1:68 
the_transitive-closure_of (X /\ Y) c= 

the_transitive-closure_of X /\ the_transitive-closure_of Y; 

The results after being looked up in the index and their corresponding frag- 
ments are written to separate files. 



4 Some Early Results 

At the time of writing, a fully working system has only just been completed. 
This means that extensive testing has not been done. Also, as only theorems have 
been used, the full power of the MML has not been exploited so extensive testing 
would be premature. Instead, these results can be regarded as a demonstration 
of potential rather than a realisation of it. 
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The tests so far fall into three categories: 

1. Can we retrieve the original theorems? 

2. Can we retrieve theorems based on part of the original theorem? 

3. Can we retrieve required theorems given a part of proof that needs a theo- 
rem? 

The first category is there as a sanity check that when throwing documents 
into the the soup of LSI, they are not lost forever. The second two are moving 
towards more realistic queries that a user might perform. First, if you are trying 
to remember a theorem in full but can only remember part, can you retrieve the 
whole theorem? Secondly, whilst working on a proof, a user might like to find 
a theorem that would prove the proof step that they are currently working on. 
Each of these categories of tests is discussed in turn. 

4.1 The Identity Query 

It is to be hoped that any query with an actual document used in the LSI would 
return that document as the best matching document. However, as mentioned 
earlier, queries can be performed with approximations based on the number of 
factors used in the similarity calculation. The unapproximated SVD of the MML 
has 106 factors. 

All of the theorems in several abstracts were used in these tests. The docu- 
ments that correspond to the theorems in these abstracts were used as queries 
but the query was only performed using 15 factors. Nevertheless, in almost ev- 
ery case, the first result returned was always the original theorem. The only 
exceptions to this were in the situation where two theorems were virtually in- 
distinguishable from each other. 

For example, the theorems TDPGRP_1 : 5 and T0PGRP_1 : 6 from [14], when used 
as queries both returned the same two theorems in that order. These theorems 
are in fact: 

theorem :: T0PGRP_1:5 
P c= Q implies P * h c= Q * h; 

theorem :: T0PGRP_1:6 
P c= Q implies h * P c= h * Q; 

As can be seen, they distinguish only in the order of the symbols that occur 
in them and as LSI does not take account of the order of terms in queries or 
documents, it is not surprising that these produced the same results. Also, from 
a user’s perspective, it would not be surprising or even undesirable to have these 
two documents returned together. 

A more surprising result from these tests came from the query based on the 
following theorem from [13]: 

theorem :: T0PS_3:10 

A is boundary implies A <> the carrier of X; 
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As expected, the query returned precisely this theorem as the best match. 
Interestingly though the second best match was the following: 

theorem :: T0PS_3:23 

A is nowhere_dense implies A <> the carrier of X; 

These are clearly quite distinct theorems from general topology but the con- 
cepts of boundary and nowhere dense are very closely related. Specifically, by 
T0PS_1 :92 [19], every nowhere dense set is boundary and hence T0PS_3: 10 im- 
plies T0PS_3:23. LSI has no explicit knowledge of these theorems. The concepts 
of boundary and nowhere dense are simply related through frequent occurrence 
in related contexts. However, this vindicates the approach taken in this use of 
LSI in that it is the linguistic use of the concept and not the logical that in some 
ways defines the semantics of the concept. 



4.2 Retrieving Full Theorems from Partial Theorems 

A single theorem can often have multiple quantifiers and, usually, it is crucial 
to know whether a theorem is an implication, equivalence or contains negations. 
However, these details may not always be remembered by a human, indeed, they 
may be the precise reason why a person would look up a theorem. 

These few tests were set up to see if, by constructing a query with a target the- 
orem in mind, it is possible to retrieve the target. The queries were constructed 
using the document version of the theorem. 

These preliminary results were somewhat mixed. Leaving out initial quanti- 
fiers does manage to retrieve the whole theorem. This works because in removing 
the variable names to convert a speculated theorem into a query, the types of the 
variables are replaced into the theorem. Where these types are known correctly, 
LSI would not distinguish between them being placed in a quantifier clause at 
the start of the theorem or in place of the variables as in these queries. Thus, 
these queries should and do work as expected. 

Also, the system is reasonably successful at retrieving theorems where the 
logical direction of the theorem is unknown. This makes sense because in Mizar, 
this is usually signified with a keyword and keywords like iff and so on play no 
role in the search and retrieval methods as implemented here. 

However, the main problem with these tests does seem to be getting the types 
of variables right. If the type of a variable is only partially entered, say entering 
only TopStruct instead of carrier of TopStruct, then the target theorem is 
not retrieved, at least not in the top 30 results. 

Two further tests looked to retrieve a theorem when the relationship between 
variables in the theorem were unknown. In the first case what should have been 
an inequality relationship in T0PS_3: 10 was guessed at by entering some likely 
candidates such as equality and subset as well as inequality. Everything else 
was as in the document version of the target theorem. In the second case, the 
inequality was omitted entirely. In both cases, the target theorem was retrieved 
as the best match. 
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4.3 Retrieving Theorems to Complete Proof Steps 

In writing a Mizar article, proofs need to give full references to theorems that are 
required to prove proof steps. In practice, this requires an extensive knowledge 
of what is (and is not) in the MML and more importantly where it is. A natural 
task for an author would be to find a theorem that applies to their current proof 
goals. 

The following tests looked at proof steps that required a single theorem to 
complete the proof. The first few were all taken from the proof of TDPS_3 : 3 in 
tops_3.miz. Topology was particularly chosen as I have some expertise in this 
area and hence the domaing knowledge needed to formulate queries. 

The first test was trying to retrieve T0PS_1:44 [19], for the following proof 
step: 

Int A c= A by TDPS_1:44 

Accordingly, the following query was generated: 

theorem Int Subset of carrier of TopStruct 
c= Subset of carrier of TopStruct 

The target theorem was indeed retrieved first by this query. 

The second test was based on: 

(Int A) /\ B c= A /\ B by XB00LE_1:26 

with the corresponding query: 

theorem set c= set implies set /\ set c= set /\ set 
This retrieved XB00LE_1:26 as the second result. 

Subsequent queries all based on steps in the same proof, however, did not 
show such promise. In each case, the query formulated did retrieve theorems that 
were certainly in the right topic but none directly pertinent to the target proof 
step. These steps all involved the notions of interior and closure of subspaces 
in topology and its was notable that a lot of the retrieved theorems tended to 
include one but not both of these concepts. Perhaps these notions were poorly 
captured by LSI. 

Two further queries (avoiding interiors and closures) were attempted, based 
on line 210 of tops_3.miz: 

G c= A by T0PS_1:20 

In this context, it was possible to formulate two queries that might have 
served well: 

theorem for Subset of TopSpace holds 
( - Subset of TopSpace ) misses Subset of TopSpace 
implies Subset of TopSapce c= Subset of TopSpace 
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theorem for Subset of carrier of TopStruct holds 
( - Subset of carrier of TopStruct ) misses 
Subset of carrier of TopStruct 
implies Subset of carrier of TopStruct c= 

Subset of carrier of TopStruct 

The target theorem was: 

theorem :: T0PS_1:20 
K c= Q iff K misses -Q; 

Whilst neither query retrieved this theorem, the second query did actually 
find the following in the top ten results: 

theorem :: PRE_TDPC:21 
for T being 1-sorted 

for P,Q being Subset of the carrier of T holds 
P c= -Q iff P misses Q; 

Though obviously distinct from the expected theorem, in fact, with a little 
work the original proof could easily be re-written to use this theorem rather than 
expected one. This then represents a significant success from a task-oriented 
perspective. 

4.4 Summary of Results 

The few tests reported here do indeed show promise though obviously the relia- 
bility of these queries is currently limited. The results are summarised in Table 1. 
All of the tests however did return results that could definitely be described as 
in the right topic for the queries. Also, as hoped for, LSI through working via 
the language of mathematics is also highlighting logical and conceptual links 
between the documents. Improving the reliability of these queries, though, is 
a clear priority and the current lines of development are discussed in the next 
section. 



5 Conclusion and Future Work 

The work done here in applying LSI to a formal mathematics library has shown 
the following: 

~ LSI can perform useful retrieval without explicit semantics 

— LSI can find conceptual associations between mathematical notions 

— Users can formulate query expressions for which LSI returns useful results 

However, there is clearly an issue with the reliability of the queries and future 
work will address this. 

Definitions and proofs were not included as documents in the LSI calculations. 
Incorporating them would increase the number of documents and could therefore 
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Table 1. Summary of Test Results 



Task 


Target type 


Query 


Outcome 


Identity 


Any theorem 
T0PS_3: 10 


The target itself 
TDPS_3:10 


Retrieves target or 
theorem with identical terms 
T0PS_3 : 23 retrieved second 
because of close 
conceptual relationship 


Partial 


Any theorem 

Any theorem 

Theorem with 
binary relation 
Theorem with 
binary relation 


Target 

without quantifiers 
Target without 
correct variable types 
Target with multiple terms 
to cover target relation 
Target with target 
relation omitted 


Successful retrieval 
Target not in top 30 
Successful retrieval 
Successful retrieval 


Proof goals 


Theorem to 
prove step 

T0PS_1:20 


Guess at target theorem 
Guess at target theorem 


Limited success 

Retrieved PRE_T0PC:21 
which could be applied 



better elucidate the terms in the MML. Actually, I strongly believe that proofs 
are the discourses of mathematics - theorems merely represent the headlines. 
Thus, including proofs as documents would provide a strong language-oriented 
foundation for the MML that I would expect LSI to exploit well. 

Making proofs into documents poses two substantial obstacles. The first and 
easiest is that so far the Mizar language has been difficult to parse with JavaCC. 
Theorems and definitions use a relatively constrained subset of the full Mizar 
grammar and so in this implementation have been parsed using a combination 
of JavaCC and bespoke finite state machines. A further implementation should 
really use a more generic and hence robust approach to parsing though it is not 
clear that this would actually overcome some of the difficulties encountered so 
far. 

The more substantial problem of including proofs as documents is the issue 
of how to represent a proof as a document. With theorems, this is relatively 
straightforward as a theorem could be viewed as a stand-alone logical statement. 
Proofs however represent a transformation between logical statements. Already, 
in trying to complete proof steps in the tests described above, I encountered 
issues of what exactly would constitute a sensible query in the context. Simple 
subsitution of variable names by the variable types, as used to turn theorems into 
documents, was not enough. Some patterns of how to formulate effective queries 
emerged and it may be possible to automate some of the query formulation 
task. In many ways, though, the formulation of queries can only be tackled on 
an empirical basis of what works well. 

A wider issue that addresses the broader aim of this work is to make gener- 
ating queries and understanding results easier to work with for a Mizar author. 
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Some form of visual interface would seem appropriate but deciding what to 
represent and how to represent it probably represents a significant design and 
evaluation effort. Related to this is whether users would want to see all the doc- 
uments that were retrieved or whether in different contexts they could rely on, 
say, just retrieving proofs or just theorems. 

In addition could further search methods or heuristics improve the reliability 
and therefore value of the LSI-based results? For instance, would these results be 
enhanced by using the filtering operations of Bancerek and Rudnicki [2]? Could 
the logical keywords like iff be used to filter suitable theorems? 

In conclusion, this work shows that using search based on the implicit seman- 
tics of a formal mathematical library does in fact yield some meaningful results. 
With further work and empirical evaluation, it is hoped that this is a step to- 
wards a full semantic search of mathematical libraries that real mathematicians 
would find useful in their work. 
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Abstract. Web Service technology is increasingly being used to develop 
distributed applications, however the convention is to describe individual 
services in terms of the interfaces that they expose, rather in terms of 
the function that they perform. In this paper we describe a mechanism 
for encoding information about mathematical web services which is rich 
enough to allow a potential client to identify automatically all those 
services which may be capable of performing a particular task. This 
mechanism makes use of the Web Ontology Language (OWL) and a novel 
approach to Description Logic reasoning exploiting enterprise database 
technologies. 



1 Introduction 

Over the last few years we have seen a growth of interest in the delivery of 
mathematical algorithms via web or grid services. Major mathematical software 
packages such as Maple (via Maplets and MapleTA) and Mathematica (via web- 
Mathematica) now offer mechanisms for remote access and use and most recently 
the market leader, Matlab 7, has provided a mechanism which allows it to act 
as a client to any web service which is implemented according to the Worldwide 
Web Consortium’s standards. Despite this, however, the vast majority of math- 
ematical software packages in use today are still installed and used locally on 
the end-user’s machine. 

It is easy to envision the impact that web service technologies could have on 
the user community: on-demand computation could be delivered by the most 
competitive software directly to the laptop of a field engineer, and the results 
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could be checked by requesting that the same computation be performed by 
multiple service providers. Complex computations could be assembled by chore- 
ographing multiple services, for instance pipelining a computation with a visu- 
alisation of the results or verifying input data validity by online reasoners prior 
to the computation. Such an infrastructure is, by its very nature, decentralised 
and ever changing, and for it to be effective requires the use of software agents 
to mediate between its different elements. In the MONET project we have de- 
veloped such an agent, called a broker, that, given a client’s description of the 
problem which it wishes to solve, will identify those services capable of solv- 
ing it. This matching process involves the storage and manipulation of a wide 
range of mathematical knowledge: formalisations of mathematical problems, the 
algorithms which can be used to solve them, the properties of particular imple- 
mentations etc. In this paper we focus on the knowledge infrastructure that the 
broker uses to describe deployed services and clients’ problems, and to match 
one to the other. A more general description of the MONET framework can be 
found in [10]. 

The Web Service Description Language (WSDL) is a way of describing the 
basic interface which a web service exposes, but it cannot be used to describe 
what the service actually does. When dealing with services that solve mathe- 
matical problems the subject area lends itself naturally to a precise, formalised, 
and unambiguous description of the abstract functionality of the service. Based 
on this idea, a mathematical service description language has been developed by 
the MONET project [18] which builds upon standards such as WSDL, RDFS, 
OpenMath and OWL [11,7,14,21]. 

A key role in these descriptions is played by the MONET ontologies, which 
not only provide the vocabulary for describing services, but formalise the rela- 
tionships between different terms in the vocabulary in a way which can be used 
by the service matcher. The ontologies are encoded using the Web Ontology Lan- 
guage (OWL) [7], the formalism chosen by the World Wide Web Consortium for 
the semantic web. The importance of OWL for the semantic web is motivated by 
its formal semantics being in Description Logics [1] (DLs), a family of knowledge 
representation formalisms evolved from early frame systems [17] and semantic 
networks [19]. DLs use an object-oriented modelling paradigm, describing the 
world in terms of individuals, concepts (classes) and roles (relationships); they 
are distinguished from their ancestors by having a precise semantics which en- 
ables the description and justification of automated deduction processes. In fact, 
they are decidable fragments of First Order Logic (FOL), and, as such, they in- 
herit its classic semantics. 

Computationally, the interest in DLs is that highly optimised reasoners have 
been developed for them. This means that we can reason over OWL ontologies in 
an effective and decidable way, and with classic FOL semantics. In particular, our 
mathematical service descriptions and queries can be automatically transformed 
into OWL descriptions using terms from the MONET ontologies. Semantically, 
service registration amounts to stating that a service is an instance of a given 
OWL description, and service matching amounts to reasoning about the asserted 
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descriptions using the MONET ontologies to find all the instances of the user’s 
query when expressed in OWL. This approach differs considerably from that of 
the related work done in the MathBroker project [2] in which registration and 
discovery is based upon ebXML [20] . 

In this particular scenario, there is no direct relation between instances. This 
means that reasoning over instances can be reduced to reasoning over their 
descriptions. From an architectural point of view, the ontology of classes can be 
treated as a static knowledge framework, while the instances are entities which 
need to be dynamically added, removed, and retrieved, and which therefore pose 
considerable management problems. 

To tackle this problem we have developed a Java component, called instance 
Store (iS) [23], where the ontology of classes is loaded from a file into a DIG [4] 
compliant DL reasoner such as RACER [12], while all the assertions over the 
instances are added to and retrieved from a database. This way, in our service 
registration and matching we can exploit robust enterprise database technology 
offering persistency, scalability, and secure and concurrent transaction manage- 
ment^. All this, while ensuring both the soundness and completeness of the 
resulting reasoning. 

This paper is structured as follows. Section 2 very briefly recalls the ba- 
sic ideas of the Mathematical Service Description Language (MSDL) while the 
MONET ontologies are reviewed in Section 3. The matching of service descrip- 
tions with the MONET ontology performed by iS and the translation of MSDL 
to OWL are the topics of Sections 4. The final section lists a few examples of 
OWL queries. 



2 Mathematical Service Descriptions 

In the web service architecture, providers of services are required to advertise 
their availability by publishing descriptions of the functionality, availability, cost, 
security and accessibility of the services they maintain. In the case of mathemat- 
ical web services, these descriptions are made more informative for the potential 
users if knowledge about certain specific aspects, which are only pertinent to 
mathematics, is given. The Mathematical Service Description Language (MSDL) 
has been designed and tailored to suit not only mathematical web services, but 
also mathematical queries and explanations. This section briefly recalls the basic 
format of a mathematical web service description, more details can be found in 
[18]. 

A mathematical service description, represented by a document in XML 
which conforms to the MONET schema, uses the MONET ontologies described 
in the following section to characterise, among others, the following aspects: 

— abstract functionality by reference to a library of mathematical problems in 
terms of input /output and precondition/postcondition specifications. 



^ Indeed, in the MONET project the iS is deployed using the JBoss EJB container. 
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— algorithmic behaviour by reference to a library of algorithms, described by 
problem solved, taxonomic and bibliographical data, 

— implementation details such as programming language, hardware platform, 
and algorithm features such as accuracy, memory-usage etc. 

— protocol, operations and data formats by WSDL [11]. 

A mathematical service description for a service called nagopt is given, in 
simplified form, in Figure 1 and shows the basic syntax of the XML formal- 
ism used in MONET. Classification of the services identifies it as a service 

<service name="nagopt"> 

<classif ication> 

<gams_class>GamsGlala</gaiiis_class> 

<problem>constrained_minimisation</problem> 

< input _f ormat >DpenMath</ input _f ormat > 

<output_f ormat>OpenMath</output_f ormat> 

<directive>f ind</directive> 

</ classif ication> 

< implement at i on> 

<sof tware>NAG_C_Library_7</ software> 

<platf orm>PentiumSystem</platf orm> 

<algorithm>Saf eguarded_Quadratic-Interpolation</algorithm> 

</ implement at ion> 

</ service> 



Fig. 1. (Simplified) MSDL description of service nagopt 



that fits the GAMS taxonomy Glala [8] (a variant of unconstrained optimi- 
sation), uses OpenMath as its I/O format, and solves a problem to find a value. 
In this case the description also gives additional details such as that the ser- 
vice is implemented using NAG’s implementation of the safeguarded quadratic- 
interpolation algorithm. The content of the problem and the algorithm el- 
ements is, in reality, a full URI reference that points to a library of prob- 
lems and algorithm descriptions. Here for example constrainedjninimisation 
is a problem of the form “minimise f{x) for x in [a, 5]”, described at http: 
/ /monet . nag . co . uk/problems/ constraineduninimisat ion. 

The following descriptions for the three services nagquad, nagroot, and 
nagopt -variation are very similar to the one given above so we have omit- 
ted the common text replacing it by .... 



<service name="nagquad"> <service name="nagroot"> <service name="nagopt-variation"> 

<classif ication> <classif ication> <classif ication> 

<gams_class>GamsH2alal</ganis_class> <gams_class>GamsF2</gaBis_class> <gams_class>GainsGla</gaiiis_class> 

<problem>def inite_integration</problem> <problem>zero_of _nonlinear_system</probleiii> <problem>constrained_minimisation</problem> 
... ... <input_f ormat>algstrl . cdg</input_format> 

</classif ication> </classif ication> 

<implementation> <impleineiitatioii> </classification> 

... ... <implementation> 

<algorithin>de_Doiicker</algorithin> <algorithin>Powell</algorithin> 

</implementation> </implementation> <platf orm>SR8000</platfomi> 

</service> </service> <algorithm>Quadratic_Prograiiiiiiing</algorithm> 

</ implementation> 

</service> 
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We will return to these examples later in this paper when we discuss how a 
client formulates a query. 

3 The MONET Ontologies 

The MONET ontologies provide a vocabulary for describing queries and services, 
and a context for the service matcher in which the relationships between different 
terms in this vocabulary are made explicit. Where possible we have re-used 
existing vocabularies and simply re-cast them in OWL [7], the Web Ontology 
Language from the Worldwide Web Consortium. We chose OWL because it 
appears to be a future standard, and it is built on existing technology such as 
RDFS [14] and DAML-hOIL [13]. 

The MONET ontologies are constructed in a modular way, with each “sub- 
ontology” referencing the external concepts it needs using the OWL imports 
statement. The current suite of ontologies is organised as follows: 

GAMS. The Guide to Available Mathematical Software (GAMS) [8] is a service 
offered by the National Institute for Science and Technology which provides 
an online index of available mathematical software classified according to the 
type of problems it solves. It is heavily biased towards numerical software 
(commercial packages from NAG, IMSL etc. and public-domain software 
such as LAPAGK, LINPAGK and the BLAS) . Unfortunately, it is extremely 
poor at classifying other kinds of mathematical software package (symbolic, 
statistical, . . . ) because it classifies the package as a whole rather than indi- 
vidual modules within the package. Nevertheless as it is the only taxonomy 
of this type we decided to use it as a mechanism for classifying services 
within the MONET framework. 

The GAMS ontology is a simple class hierarchy; each GAMS class corre- 
sponds to an OWL Glass, and specialisation of a problem class is represented 
by a sub-class relationship. For example one-dimensional quadrature is a sub- 
class of quadrature, and one-dimensional quadrature over a finite interval is 
a subclass of one-dimensional quadrature etc. 

Symbolic. To address GAMS’ shortcomings in the area of symbolic computa- 
tion, the GAMS taxonomy has been extended with a small taxonomy which 
is a sub-class of the GAMS “O” category, symbolic computation systems. 
OpenMath. OpenMath [21] is a format for the representation of mathematical 
expressions and objects. Gonstants of this language have semantics attached 
to them and are called symbols (for example sin, integral, matrix, . . .). 
Groups of related symbols are defined in content dictionaries. 

The OpenMath Ontology has one root class, DpenMathSymbol, whose 
subclasses correspond to the symbols defined in a particular content dictio- 
nary. The symbols themselves are defined as further subclasses of these. We 
use this ontology to infer a problem type as described below. 

Hardware. The hardware ontology is designed to describe either classes of 
machines or individual machines. The idea is that a user might request that a 
service run on a particular model of machine (e.g. a Sun Enterprise 10000), or 
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a general class of machine (e.g. shared memory), or a machine with a certain 
number of processors, or .... This will be used within the Implementation 
part of an MSDL service description. 

Software. The software ontology is designed to describe pieces of software. It 
is intended to be used in the implementation part of the service description 
and allows a user to express a preference for a service built using a particular 
piece of software in his or her query. 

Problems. MONET allows for a problem to be described in terms of its inputs 
and outputs, pre-conditions and post-conditions, using a specially written 
XML Schema [9]. 

Within this ontology, each problem is represented as a class, which can 
have properties indicating bibliography entries and generalisations or spe- 
cialisations of it. The most interesting property is openmathTiead whose 
range is an object from the OpenMathSymbol class. This represents a partic- 
ular symbol which can be used to construct an instance of the problem in 
question. So for example if a user sends the broker an integral of the form 




encoded in OpenMath, then the service matcher may infer that the problem 
which the user wants to solve corresponds to a sub-class of Problem whose 
openmath_head property has the value calculusl_def int. 

As well as being sub-classes of Problem, particular problems may also 
belong to GAMS classes. 

Algorithms. The algorithms ontology is designed to represent elements of the 
algorithm library in the MONET architecture. There are two subclasses in 
this ontology: Algorithm, which describes well-known algorithms for math- 
ematical computations, and Complexity, which provides classes necessary 
for representing complexity information. 

Directives. The directives ontology is a collection of classes which identify the 
task that is performed by the service as described in [9,18], for example 
decide, solve or prove. In some cases the directive needs to be associated 
with a logical theory (e.g. prove in theory T) via the inTheory property. 

Theory. The theory ontology collects classes that represents available formalised 
theories in digital libraries of mathematics. In the current version we use the 
OMDoc theories [16] in the logics and tps collections. 

Bibliography. The bibliography ontology represents entries in well-known in- 
dexes such as Zentralblatt MATH [24] and MathSciNet [15], and allows them 
to be associated with particular algorithms. This allows a client to request 
a service which implements the algorithm described in a particular paper. 

Encodings. The encodings ontology is a simple collection of classes which rep- 
resent the formats used for encoding mathematical objects in the MONET 
framework - for example the formats read and written by the services or 
used to encode explanations. 

Thus it is possible for a user to stipulate that they would like to use a 
service which takes OpenMath as input but returns MathML. 
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MONET. The MONET ontology imports all the ontologies described above 
and is used to represent complete service descriptions and queries. Not sur- 
prisingly the structure reflects that of MSDL described in Section 2 with 
an instance of the Service class having an associated Classification and 
Implementation class. These in turn may have properties linking them to 
concepts in the ontologies described above. 

The design of the ontologies has been influenced by the requirements of the 
instance Store software used for reasoning and described below. The major re- 
striction which it imposes on the ontology is that it can contain no individuals. 
As a consequence, many concepts which would most naturally be represented 
as an instance of a class (for example a particular OpenMath symbol) must be 
represented as a sub-class. This does not really limit the expressiveness of the 
ontology, but does mean that some statements are more verbose than they might 
otherwise be. In addition many (if not most) mathematical concepts form natu- 
ral hierarchies (e.g. one concept is a special case of another), so this sub-classing 
approach is often required in practice. 

When choosing names for concepts in our ontology we have tried to use 
existing URI conventions if they exist (for example the OpenMath symbol sin 
has URI h.ttp://www.openmath.org/cd/transcl\#sin), otherwise for existing 
concepts we have chosen appropriate namespaces (GAMS classes have names 
like http : //garnis .nist ,gov\#H2) while everything we have created ourselves 
lives in the MONET namespace. 



4 Service Registration and Matching 

In the MONET broker services are registered by asserting them as instances of 
OWL descriptions automatically extracted from the services’ associated MSDL 
descriptions. Service matching is then performed by posing a query in the form 
of an OWL description and then exploiting the power of DL reasoning to infer 
all services which are instances of that descriptions. 

The core component in these processes is, as mentioned in the introduction, 
the instance Store (iS) - a freely available Java application [23], developed within 
the MONET project. 

4.1 The Instance Store 

We now describe the basic functionality of the iS component. (See Figure 2 for 
the logical functionalities performed by iS of service registration and matching 
within the MONET broker architecture and see [5] for full details on iS.) 

Initialisation. The iS is initialised by providing a (“TBox”) DL reasoner (such 
as RACER), a database, and an OWL ontology (e.g. the collection of MONET 
ontologies). The iS connects to the reasoner via the DIG interface [4], and, if 
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required, loads the ontology into the reasoner after translating it to DIG. Finally, 
it connects to the database, creating the required tables if necessary. 

Adding and Removing Instances. In order to add an instance to iS, one needs to 
provide a URI for it (e.g. http : //monet .nag. co .uk/service\#nagopt) and an 
OWL description. The iS then stores this pair in the database, but also infers 
with the reasoner all the classes in the ontology which are more general than or 
equivalent to the given description, associating them with the instance’s URI in 
the database as well. This information will be used to match queries. Removing 
an instance amounts then to deleting all rows in the database involving that 
instance. 

Retrieving Instances. Retrieving all the instances of a given OWL description Q 
is more complex. First, iS uses the reasoner to find the classes in the ontology 
which are subsumed by Q and then retrieves the corresponding instances in the 
database. 

Next, iS asks the reasoner whether Q is equivalent to a class C in the ontology. 
If that is the case then also the instances corresponding to C in the database are 
returned and the procedure stops. If, however, the description is not equivalent 
to any class in the ontology, iS needs to retrieve all the instances of immediate 
parents of Q and check (again through the reasoner) whether they are, in fact, 
instances of the given description. If they are, then the relevant instances are 
also returned. 

Note that the computations involving the reasoner (parents, equivalents, 
etc) are usually performed in a fraction of a second. Coupled with the high- 
performance of databases this makes iS very efficient and scalable. 



MONET Ontologies 




Fig. 2. MONET Architecture of Service Matcher and Registry and Query Managers 








Mathematical Service Matching Using Description Logic and OWL 



81 



4.2 Prom MSDL to OWL 

When a service registers itself with the broker it submits a service description 
in MSDL. The Registry Manager component of the broker translates this into 
a description in OWL Abstract Syntax [6] by means of an XSLT stylesheet^ 
we developed (msdl2aowl.xsl in Figure 2). We favoured OWL abstract syntax 
over the XML-RDF syntax, because the former is far more concise and human 
readable when expressing the fragments of ontologies forming descriptions^. 

For instance, the description in OWL abstract syntax (AOWL) corresponding 
to the MSDL of Figure 1 is given in Figure 3, where for simplicity some of the 
restrictions “someValuesFrom(owl :Thing)” needed to ensure the existence of 
some value for each property are omitted. Thus 

restriction (property/ someValuesFromCowl : Thing) ) 

is needed not only for service_classif ication but also for every other prop- 
erty in the description. 



intersect ionOf (<http : //monet .nag. co .uk/owl#Service> 

restriction(<http: //monet .nag. co ,uk/owl#service_classif ication> 
someValuesFromCowl : Thing) ) 

restriction(<http: //monet .nag. co ,uk/owl#service_classif ication> 

allValuesFromCintersectionOf (<http: //monet .nag . co ,uk/owl#Classif ication> 
restriction(<http: //monet .nag. co ,uk/owl#gams_class> 
allValuesFrom(<http: //gams .nist . gov#GamsGlala>) ) 
restriction(<http: //monet .nag . co ,uk/owl#service_problem> 

allValuesFrom(<http : //monet . nag. co.uk/problems/constrained_minimisation>) ) 
restriction(<http: //monet .nag. co ,uk/owl#input_f ormat> 
allValuesFrom(<http : //www . openmath. org/OpenMath>) ) 
restriction(<http: //monet .nag. co ,uk/owl#output_f ormat> 
allValuesFrom(<http : //www . openmath . org/OpenMath>) ) 
restriction(<http: //monet .nag. co ,uk/owl#service_directive> 
allValuesFrom(<http : //monet . nag. co . uk/owl#f ind>) ) 

) ) ) 

restriction(<http: //monet .nag. co .uk/owl#service_implementation> 
someValuesFromCowl : Thing) ) 

restrictionC<http: //monet .nag. co .uk/owl#service_implementation> 

allValuesFromCintersectionOf C<http; //monet .nag. co .uk/owl#Implementation> 
restrict ion C<http : //monet .nag. co .uk/owl#service_software> 

allValuesFromC<http : //monet .nag . co .uk/owl#NAG_C_Library_7>) ) 
restrict ion C<http : //monet .nag . co .uk/owl#service_platf orm> 
allValuesFromC<http: //monet .nag. co .uk/owl#PentiumSystem>) ) 
restrict ion C<http : //monet .nag . co .uk/owl#service_algorithm> 
allValuesFromC 

<http; //monet .nag. co ,uk/algorithm#Saf eguarded_Quadratic-Interpolation>) ) 

) ) ) ) 



Fig. 3. Description of service nagopt in OWL abstract syntax 



Therefore, semantically, this registration corresponds to adding to the registry 
TZ the assertion D{S) (in the language used by the MONET ontologies), where 
S is a constant representing the service URL: 



^ http : / /www . cs .man. ac .uk/~dturi/ontologies/monet/msdl2owl .xsl. 

® For this reason we developed an OWL abstract syntax parser, now part of the OWL 
API [3]. 
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D{S) = Service(S) 

AV?/.(service_classif ication(S, 2/) C{y)) 

AV2/.(service_implementation(S, 2/) I{y)) 

where 

C{y) = Classif ication(2/) 

AV2;.(gams_class(22, 0) ^ GamsGlala(z)) 

AV2;.(service_problem(2/, z) constrainedjminimization(z)) 
AVz.(input_f ormat(2/, z) OpenMath(z)) 

AVz.(output_f ormat(2/, z) ^ DpenMath(z)) 

AVz.(directive(2/, z) find(z)) 

and 

I{y) = Implementation(2/) 

AVz.(software(2/, z) NAG_C_Library_ 7 (z)) 

AVz.(platf orm(2/, z) PentimnSystem(z)) 

AVz.(algorithm(2/, z) Saf eguarded_QuadraticInterpolation(z)) 



5 OWL Queries 

The simplest queries are just fragments of MSDL which provide a template for 
the service the user wishes to use. These queries are translated into OWL by 
the Query Manager component of the broker using XSLT (msdl 2 aowl .xsl in 
Figure 2 ). A simple example would consist of just a classification which contains 
a reference to a known problem (i.e. one contained in the ontology) along with 
values for the input data. In this case, in effect, the user is stating that he or 
she would like to solve this instantiation of this particular problem. Using this 
approach one may constrain the software or hardware the service runs on, the 
algorithm to be used or anything else which can be expressed in MSDL. Note 
that the class hierarchy in the ontology plays an important part here: given the 
following fragment of the algorithm ontology: 

- Algorithm 

- Quadrature 

- Automatic_AdaptiveJVIethods 

- AutomaticJMon-Adaptive_Methods 

- Fixed_AbscissaeJVIethods 
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<monet : query xmlns :monet="http : //monet .nag. co.uk/monet/ns" 
xmlns : om="http : //www. openmath. org/OpenMath"> 
<monet : problem > 

<monet : header/> 

<monet : body> 

<monet : output name=" integral "> 

<monet : value> 

<om:OMQBJ> 

<om : OMAXom : QMS name="def int " cd="calculusl "/> 

<om : OMAXom : OMS name= " interval " cd= " interval 1 " /> 
<om:OMF dec="0.0"/> 

<om:OMF dec="1.0"/> 

</om:OMA> 

<om: OMBINDXom: OMS name=" lambda" cd="fnsl "/> 

<om: OMBVARXom: OMV name="x"/x/om: OMBVAR> 

<om: OMAXom: OMS name="sin" cd="transcl"/> 
<om:OMV name="x"/> 

</om:OMA> 

</om:OMBIND> 

</om:OMA> 

</om: OMOBJ> 

</monet : value> 

</monet : output> 

</monet :body> 

</monet : problem> 

</monet : query> 



Fig. 4. A Query Involving a natural formalisation of a Mathematical Problem 



- Gauss-Hermite 

- Gauss-Laguerre 

- Gauss-Legendre 

- Gauss-Rational 

- Gill-Miller 



a user could request an algorithm which used fixed abscissae and be satisfied 
with any one of the five alternatives. 

Queries are not, however, restricted to simple templates of the service the 
user wants. The Query Manager can also construct OWL specifications based 
on other user inputs, such as that given in Figure 4. In this case the user has 
said that he or she would like the service to return the result of computing a 
particular integral, namely: 

^ 1.0 

/ sin(a:)(ia: 

Jo.o 

This is a very natural way to express this question from a mathematical point 
of view but, since there is no explicit problem, taxonomy or algorithm element 
to help the service matcher, we need to incorporate some extra information in 
the ontology to enable it to identify the problem being solved. It is immediately 
clear to a human reader^ that this is a definite integration problem. OpenMath 



^ Who is conversant with OpenMath. 
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has a tree structure and the root node for an OpenMath object can only be one 
of a small number of elements, in this case an OMA or application element. Since 
we know the structure of such elements we know that if its first child is an QMS or 
OpenMath Symbol then this is in effect the principle constructor for the object. 
In this case the symbol is that one used to represent definite integration (def int 
from the content dictionary calculus 1). 

Elements of the Problem Ontology may have the property openmath_head 
which indicates an OpenMath symbol which can be used to construct instances 
of that problem. In fact the def inite_integration class in the Problem on- 
tology has an openmathJiead property of def int. So if the Query Manager 
transforms this query to a request to solve problems with an openmath_head 
property of def int then the reasoner will infer that any service solving the 
def inite_integration problem is a candidate. 

We now illustrate service matching by considering five queries to an elemen- 
tary iS consisting of four services. 

The first query asks for all individuals whose GAMS classification is GamsG: 
iS answers it by returning nagopt and nagopt -variation. 

rGstriction(<http : //monet .nag. co ,uk/owl#SGrvicG_classif ication> 

someValuesFrom (restriction (<http: //monet .nag. co .uk/owl#gams_class> 
someValuesFrom(<http : //gams .nist ,gov#GamsG>) ) ) ) 



The second example is a query for all individuals whose implementation has 
Root_Finding as algorithm. In the Algorithm ontology we can find that Powell 
is a child of Root_Finding. And, indeed, the answer of iS to the query is nagroot. 

restriction(<http : //monet .nag. co .uk/owl#servicG_implementation> 

someValuesFrom (restriction (<http: //monet .nag. co .uk/owl#service_algorithm> 
someValuesFrom (<http : //monet .nag. co .uk/algorithm#Root_Finding>) ) ) ) 



We can generalise the query by replacing Root .Finding with Numeric and 
obtain all services as answers, since they are all numeric. 

The next query is more interesting: we ask for all individuals with algorithm 
having a Zentralblatt bibliographic reference 0277.65028. The answer is again 
nagroot, since in the Bibliography ontology we have associated that reference 
to Powell. 

restriction(<http : //monet .nag. co .uk/owl#servicG_implementation> 
someValuesFrom (restrict ion (<http : //monet .nag. co .uk/owl#service_algorithm> 
someValuesFrom(restr ict ion (<http : //monet . nag . co . uk/algorithm#bibliographic_ref erence> 
someValuesFrom ( intersect ionOf (<http : //monet .nag. co .uk/bibliography#ZentralBlatt_MATH> 
restrict ion (<http : //monet .nag. co .uk/bibliography#bibref > 
value ("Zbl_0277 . 65028" '‘''<http: //www. w3 . org/2001/XMLSchema#string>) )))))))) 



We now illustrate the use of negation in a query. Consider first the query 
where we ask for all individuals running on a platform with one processor. 

restriction(<http: //monet .nag. co .uk/owl#service_implementation> 
someValuesFrom (restrict ion (<http : //monet . nag. co . uk/owl#service_platf orm> 
someValuesFrom (restriction (<http: //monet .nag . co .uk/owl#number_of _processors> 
value ("1" ■''‘<http : //www. w3 . org/2001/XMLSchema#int>) ) ) ) ) ) 



The answer is nagopt, nagroot, and nagquad, but not nagopt -variation 
since we asserted that it runs on SR8000 which is a parallel processor. Now, 
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if we add to the Hardware ontology the axiom that Serial and Parallel are 
disjoint, we can infer that not (Parallel) is equivalent to Serial, and hence 
the next query would also return nagopt, nagroot, and nagquad. 

intersectionOf (<http : / /monet . nag . co . uk/ owl#Service> 
restriction(<http: //monet .nag. co .uk/owl#service_implementation> 
someValuesFrom (restrict ion (<http : //monet .nag. co . uk/owl#service_platf orm> 
someValuesFromC complement Of (<http : //monet . nag. co . uk/owl#Parallel>) ) ) ) ) ) 



In terms of the first-order deduction relation ‘h’, querying for the services 
matching a description given in a query Q{x) amounts to retrieving the set of 
services whose description is subsumed by the query: 

{S I b D(S) Q{S) for some -D(S) G 71} 
with respect to the MONET ontologies At and the assertions in the registry 71. 



6 Conclusions 

The MONET ontologies are designed to model both queries and service descrip- 
tions: in that sense they are a formalism of the original MSDL language which 
was deliberately designed to be “ontology neutral” . This was partly to make the 
task of authoring service descriptions more straightforward (since the language 
is quite compact), but mainly because OWL was then at an early stage of devel- 
opment. The ontologies are designed to be used by the broker and, in particular, 
the iS component which is responsible for matching queries to appropriate ser- 
vices. This component is, in turn, built on a Description Logic reasoner accessed 
through the generic DIG interface. In our case we have chosen to use RACER 
for this purpose, but there are several other alternatives which we could have 
used equally well. 

We have demonstrated how one may use OWL to discover appropriate ser- 
vices to solve particular mathematical problems. This was intended as a proof- 
of-concept exercise and there are still aspects which could be improved. The 
ontologies themselves are somewhat sparse in some areas - our symbolic ex- 
tension to GAMS for example - but we are loth to extend them purely as an 
academic exercise. The beauty of GAMS is that it is a categorisation of an exist- 
ing set of resources and we feel that this is the right approach to take, however 
we are aware that it took a considerable effort to develop and it was not practical 
to do something on a similar scale within MONET. 

One possible approach would be to allow for dynamic extension of the on- 
tologies, so that (for example) if a service deployer registered a new problem in 
the Problem Library it would automatically be added to the problem ontology 
and the service-matcher components of the running browsers could be notified 
to re-initialise their versions of iS. This is not a perfect solution since it would 
allow for inaccurate or incomplete entries to be added to the ontologies, and of 
course it only really applies to leaf nodes. 

The process of converting a query into the appropriate OWL format is im- 
portant since this allows us to extend the possible mechanisms for formulating 
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queries beyond simply asking the client to provide a fragment of MSDL. The 
technique we described of taking a problem description and inferring the problem 
type from its OpenMath structure is widely applicable and reflects the way in 
which human users usually interact with packages such as Maple, Matlab etc., by 
typing in strings such as “int(sin(x) ,x=0. .1)”. However there are other ways 
of stating mathematical problems which use the desired properties of the result 
such as “And all x G C | = 1” . The condition here is in effect a post-condition 

of the problem description. 

Matching on pre- and post-conditions would be a very powerful technique, 
partly because it would give the user much more freedom in formulating problems 
but also because it would help automate service orchestration. Services whose 
post- and pre-conditions matched could be “plugged-into” each other. However it 
is a well-known fact that proving that two mathematical expressions are identical 
is in theory undecidable [22] (although there are many mechanisms which will 
solve a large class of cases in practice). Given that we have access to general- 
purpose computer algebra systems such as Maple within the MONET framework 
it would not be too difficult for a broker to use them as oracles to decide whether 
two statements were equivalent. 

Although the application we have investigated is that of advertising and 
discovering web services the same general framework could be used for describing 
and cataloguing any kind of mathematical software, or indeed for describing the 
individual functions available within a comprehensive software package such as 
the NAG Library or Maple. 
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Abstract. We present C-CoRN, the Constructive Coq Repository at 
Nijmegen. It consists of a mathematical library of constructive algebra 
and analysis formalized in the theorem prover Coq. We explain the struc- 
ture and the contents of the library and we discuss the motivation and 
some (possible) applications of such a library. 

The development of C-CoRN is part of a larger goal to design a 
computer system where ‘a mathematician can do mathematics’, which 
covers the activities of defining, computing and proving. An important 
proviso for such a system to be useful and attractive is the availability 
of a large structured library of mathematical results that people can 
consult and build on. C-CoRN wants to provide such a library, but it can 
also be seen as a case study in developing such a library of formalized 
mathematics and deriving its requirements. As the actual development 
of a library is very much a technical activity, the work on C-CoRN is 
tightly bound to the proof assistant Coq. 



1 Introduction 

A repository of formalized constructive mathematics [6] in the proof assistant 
Coq [13] has been constructed over the last five years at the University of Nij- 
megen. This is part of a larger goal to design a mathematical assistant: a com- 
puter system in which a mathematician can do mathematics. This covers the 
activities of defining (theory development), computing (programming) and prov- 
ing (proof development) , but ideally also editing of mathematical documents and 
presentation of mathematics. In such a computer system, the mathematics would 
obviously have to appear in a formalized form, i.e. as expressions in some formal 
language. The process of going from the informal (paper) mathematics to the 
mathematics that can be understood and manipulated by a computer (program) 
is called formalization. 

One of the things that is very important for such a ‘mathematical assistant’ 
to be used is the availability of a large and usable library of basic results. A 
library will make it attractive for potential users to experiment with the system 
and to contribute results to its repository. Such a repository should not be just a 
huge collection of proved results (including the ‘proof scripts’ that are input for 
the proof assistant to carry out the proof). In our view, a library of formalized 
mathematics should be: 
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Accessible: one should be able to get a fairly fast overview of what’s in it and 
where to find specific results; 

Readable: once one has come down to the basic objects like definitions, lemmas 
and proofs, these should be presented in a reasonable way; 

Coherent: results about a specific theory should be grouped together and the- 
ories extending others should be defined as such; 

Extensible: contributions from other researchers should be easy to include. 

How can one make such a (large) coherent library of formalized mathematics? 
Ideally, this should also be independent of the Proof Assistant one is working 
with, but right now that cannot be done. Several other projects deal with this 
question. The MoWGLI project [2] aims at devising system-independent tools 
for presenting mathematics on the web. The OpenMath [10] and OMDoc [25] 
standards aim at exchanging mathematics across different mathematical appli- 
cations, which is also one of the aims of the Calculemus project [8]. This may 
eventually lead to ways of sharing mathematical libraries in a semantically mean- 
ingful way that preserves correctness, but this is not possible yet (an exception 
is NuPRL, which can use HOL results [29]). 

So, to experiment with creating, presenting and using such a library, one has 
to stick to one specific theorem prover, and already there many issues come up 
and possible solutions can be tested. We have chosen to use the Coq Proof Assis- 
tant, because we already were familiar with it and because we were specifically 
interested in formalizing constructive mathematics. 

This paper first describes the backgrounds of C-CoRN: its history and mo- 
tivation. Then we describe the structure of the repository as it is now and the 
methodology that we have chosen to develop it. Finally we discuss some appli- 
cations and future developments. 



2 History 

The C-CoRN repository grew out of the FTA project, where a constructive proof 
of the Fundamental Theorem of Algebra was formalized in Coq. This theorem 
states that every non-constant polynomial / over the complex numbers has a 
root, i.e., there is a complex number z such that /(z) = 0. 

One of the main motivations for starting the FTA project was to create a 
library for basic constructive algebra and analysis to be used by others. Often, 
a formalization is only used by the person that created it (or is not used further 
at all!), whereas an important added value of formalizing mathematics - in our 
view - is to create a joint computer based repository of mathematics. For the 
FTA project, this meant that we did not attempt to prove the theorem as fast 
as possible, but that in the proving process we tried to formalize the relevant 
notions at an appropriate level of abstraction, so that they could be reused. 

An important condition for the successful use of a library of formalized math- 
ematics is to have good documentation of the code. There are two main purposes 
of documentation: 
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1. to show to the world what has been formalized via a ‘high level’ presen- 
tation of the work (in our case that would be a MrgX document giving a 
mathematical description of the formalized theory); 

2. to help the interested outsider to extend (or change or improve or vary on) 
the formalized theory. 

For (1) one wants to produce a I^T^X document that ‘goes along’ with the 
formalization. This may be generated from the formalization (but it is not quite 
clear whether it is at all possible to generate something reasonably, and math- 
ematically abstract, from the very low level formal proof code). Alternatively - 
and this is the approach followed in the FTA project - this IAr[;]X file may be cre- 
ated in advance and then used as a reference for the proof to formalize. The goal 
of the FTA project was to formalize an existing proof and not to redo the math- 
ematics or ‘tailor’ the mathematics toward the proof assistant. This meant that 
we started from an original proof of FTA, described in [22] , with lots of details 
filled in to ease the formalization process. The same approach has been followed 
throughout the rest of C-CoRN: existing mathematics is formalized, so the (high- 
level) mathematical content corresponds to an existing part of a book or article. 

For (2), some simple scripts were created in the FTA project to be able to 
extract from the Coq input files a useful documentation for outsiders interested in 
the technical content. However, this was pretty ad hoc and not very satisfactory, 
and it was changed in C-CoRN, as described in Section 5. 

After the FTA project was finished, i.e., after the theorem had been formally 
proved in Coq, it was not yet clear that it had been successful in actually creating 
a usable library, because all people working with the library until then were part 
of the project. The only way to test this would be to let outsiders extend the 
library. This is not too easy: due to the fact that we have tactics implemented in 
ML (e.g. to do equational reasoning), one cannot use the standard image of Coq 
and has to build a custom image first. Therefore, the first real test only came 
when the first author of this paper started as a new Ph.D. student to formalize 
constructive calculus (leading to the Fundamental Theorem of Calculus) in Coq. 
The FTA library turned out to be very usable. Most importantly, there was 
almost no need to restructure the library or redefine notions, implying that most 
of the basic choices that were made in the FTA project worked. (Of course, the 
basic library was extended a lot, with new results and new definitions.) Hereafter, 
the library was rebaptized to C-CoRN, the Constructive Coq Repository at 
Nijmegen, since the FTA and the work of the FTA project had become only a 
(small) part of it. 

Since then, several people, working both in Nijmegen and elsewhere, have 
consulted, used and contributed to C-CoRN. These have found its structure 
(including notations, automation facilities, documentation) quite useful. 



3 Why C-CoRN? 

Formalizing mathematics can be fun. In the process of formalizing, one discovers 
the fine structure of the field one is working with and one gains confidence in 
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the correctness of the definitions and the proofs. In addition to this, formalizing 
mathematics can also be useful. We indicate some of its possible uses: 

Correctness Guaranteed: The formalized mathematics is checked and there- 
fore the proofs are guaranteed to be correct for all practical purposes. This 
can be vital in the realm of software or system correctness, where one wants 
to be absolutely sure that the mathematical models and the results proved 
about them are correct. 

Exchange of ‘Meaningful’ Mathematics: That the mathematics is formal- 
ized means that it has a structure and a semantics within the Proof Assistant. 
So a mathematical formula or proof is not just a string of symbols, but it 
has a structure that represents the mathematical meaning and its building 
blocks have a definition (within the Proof Assistant) . These can in principle 
be exploited to generate meaningful documents or to exchange mathematics 
with other applications. 

Finding Mathematical Results: Based on the semantics and the structure 
of the formalized mathematics, it should be possible to find results easier. 
Querying based on the (meaningful) structure is already possible (imple- 
mented in the Helm system, see [23]), but more semantical querying would 
be welcome. This requires adding more meta-data. 

The potential uses of formalized mathematics only really become available if 
one can share the formalization and let others profit from it, e.g. by making it 
possible for them to study it, extend it or use it for their own applications or 
further development. A key requirement for this is that the formalized mathe- 
matics be presented. Ordinary (non-computer-formalized) mathematical results 
are published in articles, books or lecture notes, and are in that way shared with 
other mathematicians or users of mathematics. Giving a good presentation of 
formalized mathematics in practice, though, turns out to be quite hard. There 
are various reasons for this: 

Idiosyncrasies of the Proof Assistant: When talking to a Proof Assistant, 
things have to be stated in a specific way, so the system understands it: 
definitions have to be given in a specific format, proofs have a specific form, 
etc. Moreover, each Assistant has its own logical foundations (e.g. set theory, 
type theory or higher order logic), making it easy to express some concepts 
(e.g. inductive definitions in type theory) and hard to express others (e.g. 
subsets in type theory). Because of this, mathematical theory will be defined 
in a specific way that best fits the idiosyncrasies of the system at hand. 
When presenting the formal mathematics, one would like to abstract from 
these ‘arbitrary’ choices. 

Verbosity of Formalized Mathematics: To make the Proof Assistant un- 
derstand (or be able to verify) what the user means, a lot of details have 
to be given. By itself, this is unavoidable (and fine, because we really want 
the mathematics to be verified and that doesn’t come for free). But in the 
presentation phase, one wants to abstract from these finer details and ‘view’ 
the mathematics at a higher level. This is not so easy to achieve. Ideally it 
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would also be possible to use the higher level (less verbose) mathematics as 
input for the proof assistant, but that’s not easy either. 

Access to the Formalized Mathematics: How does one find a result in the 
library, how does one get an overview of the material? One can query the 
library with syntactic means, searching a formula of a specific form, as 
described in [23]. This is helpful, but can a useful result still be found 
if it occurs in the library in disguise? Also, if a user knows that a spe- 
cific lemma appears in the library, (s)he will want to apply it, which in a 
Proof Assistant is done by using its name. But what is the name of (the 
proof of) a lemma? One probably doesn’t want to clutter up the names 
in the presentation of the math, so ‘logical’ naming conventions come in 
handy. 

To really understand and work on these points, one needs a ‘testbed’ to 
experiment with. This was one of the reasons to start C-CoRN: to have a library 
of mathematics that people can really contribute to, read and work with. 

Of course, such libraries already exist. The prominent one is the Mizar 
Mathematical Library (MML). However, Mizar was not good for experiment- 
ing with a library of formalized mathematics, because we would not have con- 
trol over the library: one cannot just install Mizar and formalize a large library 
on top of the existing one. Soon the system gets slow and one has to sub- 
mit the work to the Mizar library to have it integrated. Moreover, the Mizar 
system itself is not open in the sense that one can program one’s own tools 
(e.g. for automation or documentation) on top of it^. Another important rea- 
son not to choose Mizar was that we were aiming at a library of constructive 
mathematics. For all these reasons, Coq was a good choice, with the drawback 
that there was only a very small initial library to begin with. (There are many 
‘Coq contributions’, but they do not form one coherent library as discussed in 
Section 8.) 

The main reason for working constructively is that we want to use our 
library, apart from studying how it conducts as a repository, to study the con- 
nections between ‘conceptual’ (abstract) mathematics and ‘computational’ (con- 
crete) mathematics. The first (conceptual math) deals with e.g. the proof 
of (and theory development leading to) the Fundamental Theorem of Alge- 
bra, while the second (computational math) deals with an actual represen- 
tation of the reals and complex numbers and the actual root finding algo- 
rithm that the FTA exhibits. In this paper we will not elaborate on this any 
further, but just point out that this was an important motivation for choos- 
ing to work with Coq. At present work is being done in program extraction 
from the C-CoRN library, and this relies heavily on the fact that the library is 
constructive. 



^ Right now, C-CoRN is not open either: we want to have ‘central control’ over the 
library. But the point we want to make here is that the Proof Assistant Coq, on 
which C-CoRN is based, is open. 
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4 Contents 

C-CoRN includes at present formalizations of significant pieces of mathematics. 
In this section we give an overview of the main results in the library. So far ev- 
erything has been formalized constructively. Although we do not exclude adding 
non-constructive theorems to the library, working constructively has some added 
value, as indicated in the previous section. 

The C-CoRN library is organized in a tree-like fashion. This structure agrees 
with the dependencies among the mathematics being formalized. In Figure I the 
directory structure of C-CoRN can be seen. 




Fig. 1. Directory structure of C-CoRN 

At the bottom of C-CoRN are the tactic files and the Algebraic Hierarchy, 
developed in the framework of the FTA project. Most of the tactics are to make 
equational reasoning easier, see [21]. In the Algebraic Hierarchy, the most com- 
mon algebraic structures occurring in mathematics, such as monoids, rings and 
(ordered) fields, are formalized in a cumulative way and their basic properties 
are proved. For reasons discussed in Section 5, this formalization proceeds in an 
abstract way, described in detail in [19]. Furthermore, the hierarchy is built in 
such a way that more complex structures are instances of simpler ones, i.e. all 
lemmas which have been proved e.g. for groups are inherited by all ordered fields. 

One might argue that tactics should not be part of a library of mathematics 
but are ‘meta-knowledge’. However in C-CoRN the tactics are closely related to 
the lemmas that they depend on: these cannot be easily separated. Also lemmas 
and tactics can be exchanged for each other: a proof step often can be made 
either with reference to a lemma (declarative mathematical knowledge) or by 
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applying a tactic (procedural mathematical knowledge). For these reasons we 
consider tactics to be part of the C-CoRN library. 

Real number structures are defined as complete archimedean ordered fields. 
The C-CoRN library includes not only a concrete model of the real numbers 
(namely, the standard construction as Cauchy sequences of rationals) but also 
a formal proof that any two real number structures are equivalent and some 
alternative sets of axioms that can be used to define them. Thanks to these 
results, it makes sense to work with a generic real number structure rather than 
with any concrete one. This part of the library is described in detail in [18]. 

Among generic results about real numbers included in the library we point 
out the usual properties of limits of Cauchy sequences and the Intermediate 
Value Theorem for polynomials, which allows us in particular to define roots 
of any nonnegative number. 

At this point the library branches in various independent directions. 

One of the branches consists of the rest of the original FTA library, which 
contains the definition of the field of complex numbers and a proof of the Fun- 
damental Theorem of Algebra due to M. Kneser; this work is discussed in [22]. 
Other important results in this part of the library include the definition of im- 
portant operations on the complex numbers (conjugation, absolute value and 
^th j.QQ|;gj their properties. 

The second main branch deals with a development of Real Analysis follow- 
ing [4]. Here, properties of real valued functions are studied, such as continuity, 
differentiability and integrability. Several important results are included, among 
which Rolle’s Theorem, Taylor’s Theorem and the Fundamental Theorem of Cal- 
culus. Also, this segment of the library includes results allowing functions to be 
defined via power series; as an application, the exponential and trigonometric 
functions are defined and their fundamental properties are proved. Logarithms 
and inverse trigonometric functions provide examples of function definition via 
indefinite integrals. 

A separate branch of the library, currently in its initial stage of development, 
deals with topological and metric spaces. At present this part of the library is 
very small; it includes simple properties of metric spaces, as well as a proof that 
the complex numbers form a metric space. 

The sizes of the different parts of the C-CoRN library are shown in Figure 2. 
This data does not include the files dealing with metric spaces, as these are still 
in an early stage of development, nor those dealing with applications to program 
extraction, which will be discussed in Section 6. 



Description 


Size (Kb) 


% of total 


Algebraic Hierarchy (inch tactics) 


533 


26.4 


Real Numbers (inch Models) 


470 


23.3 


FTA (inch Complex Numbers) 


175 


8.7 


Real Analysis (inch Transc. Fns.) 


842 


41.6 


Total 


2020 


100 



Fig. 2. Contents and size of C-CoRN (input files) 
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5 Methodology 

In order to successfully pursue the goal of formalizing a large piece of mathe- 
matics, it is necessary to work in a systematic way. In this section we look at 
some of the general techniques that are used to make the development of the 
C-CoRN library more fluent. 

We will focus on four main aspects: 

Documentation: In order to be usable, a library needs to have a good docu- 
mentation that allows the user to quickly find out exactly what results have 
been formalized, as well as understand the basic notations, definitions and 
tactics. 

Structuring: Another important issue is the structure of the library. We feel 
that lemmas should be somehow grouped according to their mathematical 
content rather than to any other criterion; e.g. all lemmas about groups 
should be put together in one place, all lemmas about order relations in 
another, and so on. A related aspect is how to name lemmas. Experience 
shows that following some simple rules can make the process of looking for 
a particular result both easier and faster. 

Abstract Approach: C-CoRN aims at generality. This suggests that mathe- 
matic structures (e.g. real numbers) be formalized in an abstract way rather 
than by constructing a particular example and working on it. We will exam- 
ine some of the consequences of this style of working. 

Automation: Finally, any successful theorem-proving environment must have 
at least some automation, otherwise the proving process quickly becomes 
too complex. We give an overview of the specific tactics that were devel- 
oped for C-CoRN and show how they help in the development of the li- 
brary. 

Documentation 

Providing a good documentation for the formalized library in parallel with its 
development was a central preoccupation from the beginning of the FTA project. 
In fact, having a human-readable description of what has been formalized can 
be very useful in communicating not only content but also ideas, notations and 
even some technical aspects of the formalization process. 

Such a documentation should at any given moment reflect the state of the 
library, and as such should be intrinsically linked to the script files. (This is also 
the idea behind Knuth’s ‘Literate Programming’. Aczel and Bailey use the term 
‘Literate Formalization’ for this method applied to formalized mathematics [3].) 
At present, Coq provides a standard tool, called coqdoc (see [17]), that auto- 
matically generates postscript and html documentation from the Coq input files. 
Additional information can be introduced in the documentation via comments 
in the script file. 

Ideally the documentation should be one with the script files; however this 
is not the situation in Coq. In this system the standard way to generate docu- 
mentation for a library is using coqdoc, and this is the way we do it in C-CoRN. 
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The C-CoRN documentation includes all definitions, axioms and notation as well 
as the statements of all the lemmas in the library, but no proofs: being meant 
as documentation, rather than presentation of the library, the presence of long 
and incomprehensible proof scripts in the documentation would undermine its 
purpose. For the same reason, tactic definitions are omitted from the documen- 
tation, but not their description: although the actual code is not presented, the 
behavior of the existing C-CoRN specific tactics is explained as well as how and 
when they can be used. 

In the html version, hyperlinks between each occurrence of a term and its 
definition allow the users to navigate easily through the documentation, being 
able to check quickly any notion they are not familiar with. 



Structuring 

There are several ways that the lemmas and files in a library of formalized math- 
ematics can be organized. The current trend in most major systems, as discussed 
in Section 8, seems to be adding individual files to the library as independent 
entities and seldom if ever changing them afterward (except for maintenance). 
However, C-CoRN is intended as a growing system upon which new formaliza- 
tions can be made. The approach above described directly conflicts with this 
purpose, for it typically leads to dispersion of related lemmas throughout the 
library and unnecessary duplication of work. 

For this reason, lemmas in C-CoRN are organized in files according to their 
statements and files are distributed in directories according to their subjects. 
Thus, different areas of mathematics appear in different directories and different 
subjects within one area will be different files in the same directory. 

The disadvantage of this approach is that it requires some form of central 
control over the repository: after an extension, the library has to be reconsid- 
ered to put the definitions and lemmas in the ‘right’ place. This may become 
problematic if many files are contributed within a short time. Presently the 
responsibility for maintaining different parts of C-CoRN is distributed among 
different people: when a subject becomes extensively represented in the library, 
we encourage the developers of that subject to take responsibility for it. In 
this way we do not restrict the control of the library to a small group of peo- 
ple or a confined geographical location, but we manage to keep its unity. We 
also hope that new users will feel motivated to work in C-CoRN and extend 
it. 

No part of the library is, strictly speaking, immutable: new lemmas can be 
added at any time to existing files, if they are felt to belong there. In this 
way, new lemmas then become immediately available to other users. In practice, 
though, the lower in the tree structure of Figure 1 a file is, the less often it will 
be changed. 

Coupled with this method of working, the documentation system described 
above makes looking for a particular statement a simpler process than in most 
of the systems the authors are acquainted with. But in addition to this, naming 
conventions are adopted throughout C-CoRN that allow experienced users to 
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find a specific lemma even more quickky without needing to consult the docu- 
mentation. These naming conventions are too specific to be explainable in a short 
amount of space; the interested reader can find them throughout the C-CoRN 
documentation. 



Abstract Approach 

One finds two approaches to formalizing algebraic operations. On the one hand 
one just has concrete types for various number structures, like the natural num- 
bers, the integers, the real numbers and the complex numbers, and for each of 
those one defines a separate set of arithmetical operations. On the other hand - 
which is the approach that is followed in C-CoRN, as described in [19] ~ one can 
have a hierarchy of the commonly appearing algebraic structures in mathemat- 
ics, such as groups, rings, fields and ordered fields, and then instantiate these to 
specific number structures. In this approach the theory of the real numbers will 
not refer to a specific type of real numbers, but just to a type of ‘real number 
structure’, which later can be instantiated to a concrete modeP. 

This second approach has advantages and disadvantages. An advantage is 
that the theory that is developed for a certain structure is maximally reusable. 
For example, the group properties can be reused for the integers, the rational 
numbers, the real numbers, polynomials, vectors in a vector space, and so on. 
In our abstract approach each of these structures will be just an instance of the 
already existing algebraic type of groups, and the laws that were proved for this 
type will be immediately available. In the first approach the same theory has 
to be developed over and over again every time a new structure with the same 
algebraic properties is defined. 

Another advantage is that the same notation will be used for the same alge- 
braic operation. This is especially useful in a system that has no overloading, like 
Coq. For instance, in the first approach one has different additions on natural 
numbers, integers, real numbers, while in C-CoRN all of these are simply written 
as (x[+]y). 

A third advantage is that the development of the theory will more closely 
follow the development of algebra in a mathematical textbook. 

The main disadvantage of the abstract approach is that the terms that occur 
in the formalization are usually much bigger, because they have to refer to the 
specific structure used. Also, because of the hierarchy of the types of algebraic 
structures, there will be functions needed in the terms to get to the right kind of 
algebraic structure. This is not a problem for the user, since all these operations 
are implicit: the specific structure is generally an implicit argument, while the 
functions that map algebraic structures are coercions. But internally these terms 
are big, so it slows down the processing of the formalization by Coq. 



^ In C-CoRN this algebraic hierarchy is formalized using record types, making the 
abstract structures first class citizens (types) of the system. Another way to proceed 
(which wasn’t available at the time C-CoRN was started) would be to use Coq’s 
modules. 
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Another slight disadvantage of this approach is that sometimes proofs can 
be less direct than in the case where all functions are concretely defined. This 
also affects program extraction. For instance, if one knows that one is dealing 
with the rational numbers, a proof might be possible that gives a much better 
extracted program. In the case that one has to give a proof from an abstract 
specification, this optimization might not be available. 

Automation 

An important part of the C-CoRN library consists in tools designed to aid in 
its own development. Together with definitions, notations and lemmas, several 
automated tactics are defined throughout C-CoRN. 

These tactics vary in complexity and in their underlying mechanism. Thus, 
there are several tactics based on Coq’s Auto mechanism, which simply per- 
forms Prolog-style depth-first search on a given collection of lemmas. Each tac- 
tic is designed for a specific subject, such as equational reasoning in different 
algebraic structures (Algebra) or proving continuity of real-valued functions 
(Contin). 

Other tactics base themselves on the principle of reflection to tackle wider 
classes of problems in a more uniform and more efficient way. We mention 
rational, described in detail in [19], which provides proofs of equalities in rings 
or fields, but can solve a much larger class of goals than Algebra; and Deriv, 
described in [14], a reflective tactic which can prove goals of the form f = g 
when / and g are real-valued (partial) functions. Although tactics based on re- 
flection are usually more powerful than those based on Auto, they are also more 
time consuming when the goals are simple and usually cannot infer as much 
information from the context as the latter. 

Finally, an interface for equational reasoning is also provided via the step 
tactic. This tactic allows the user to replace a goal of the form R{a,b), where 
i? is a relation and a and b have appropriate types, by either R{c, b) or i?(a, c), 
where c is a parameter given by the user. This tactic looks through a database 
of lemmas that state extensionality of (various types of) relations, and chooses 
the one which applies to R. Then it applies either Algebra or rational to prove 
the equational side condition generated by the lemma. 

The step tactic has been generalized to work in a much wider domain than 
that of C-CoRN and is now included in the standard distribution of Coq. 



6 Applications 

Besides the direct interest of formalizing mathematics per se, there are some 
interesting applications that are either being explored at present or are planned 
for the near future. 

One of the consequences of working constructively, and therefore without any 
axioms, is that, according to the Curry-Howard isomorphism, every proof is an 
algorithm. In particular, any proof term whose type is an existential statement 
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is also an algorithm whose output satisfies the property at hand. This allows us 
to obtain correct programs for free, which is an interesting possibility. 

In Coq there is an extraction mechanism available that readily transforms 
proof terms into executable ML-programs (see [26]). Marking techniques are used 
to reduce the size of extracted programs significantly, as most of the information 
in the proofs regards correctness rather than execution of the algorithm and 
can be safely removed. In [15] it is described how this extraction mechanism 
was used to obtain, from the formalized proof of the Fundamental Theorem of 
Algebra, an algorithm that computes roots of non-constant polynomials. At the 
time of writing the extracted program is too complex and does not produce any 
output in a reasonable amount of time; but the same method has been used to 
produce a correct program that can compute 150 digits of e in little over one 
minute. 

Of course, the performance of these extracted programs can in no way com- 
pete with that of any existing computer algebra system. For these reasons other 
approaches to proving correctness of programs are known and studied in com- 
puter science. However, we feel that in situations where correctness is more 
important than speed, program extraction might one day be successfully used. 

7 Future Developments 

There are presently a number of different directions in which we would like to 
see C-CoRN extended in a near future. 

One goal is to extend the library by adding new branches of mathematics to 
the formalization or by building upon existing ones. In particular, the following 
areas are considered important: 

Complex Analysis: Presently there exist a usable algebraic theory of complex 
numbers and a formalization of one- variable Real Calculus. These provide a 
basis upon which a formalization of Complex Analysis can be built. 

Basic Topology: There are no general topology results available in C-CoRN 
yet; a development of the elementary properties of topological spaces would 
not only extend the library, but would probably make it possible to unify 
different parts of the library where instances of the same general lemmas are 
proved for specific structures. 

Metric Spaces: Similarly, several of the properties of the absolute value op- 
eration on real numbers and its correspondent on complex numbers are in 
fact instances of properties which can be proved for any distance function 
on a metric space. We hope that the small development currently existing 
in C-CoRN will enable us to prove these and other similar results in a more 
uniform manner. 

Number Theory: On a different line, number theory seems to be a subject 
where an attempt at formalization could be very successful, since Coq is 
a system where it is for example very easy to use induction techniques. 
Furthermore, the preexistence of a library of real analysis would make it 
much easier to prove results which require manipulating specific integrals. 
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Group Theory: This is also a subject that would be interesting to explore 
in C-CoRN. Although we have built an algebraic hierarchy which includes 
monoids, groups and abelian groups among its inhabitants, so far most of the 
development has been done only when at least a ring structure is available. 
Formalizing important results of group theory would be an important test 
ground for the usability and power of the algebraic hierarchy. 

On a different note, we would like to develop applications of C-CoRN. There 
are currently plans to do this in two different ways: 

Program Extraction: The new extraction mechanism of Coq [26] has made it 
possible to extract and execute programs from the C-CoRN library, as has 
been explained in [16]. However, the results so far have been slightly disap- 
pointing. Recent work has shown that much improvement may be obtainable, 
and we hope to pursue this topic. 

Education: A formalization of basic algebra and analysis should not only be 
useful for additional formalizations (by researchers) but also for students, 
who can use it as course material. This addresses a different audience, to 
which the material has to be explained and motivated (using lots of exam- 
ples). We believe that a formalization can be useful as a starting point for 
an interactive set of course notes, because it gives the additional (potential) 
advantages that all the math is already present in a formal way (with all the 
structure and semantics that one would want to have) and that one can let 
students actually work with the proofs (varying upon them, making inter- 
active proof exercises). In the Algebra Interactive project (see [11]), a basic 
course in Algebra has been turned into an interactive course, using applets 
to present algebraic algorithms. Another experience, on the presentation of 
proofs in interactive course notes, is reported in [7]. We want to investigate 
C-CoRN as a basis for such a set of course notes. 

For usability it is very important to have good automation tactics and power- 
ful (or at least helpful) user interfaces. Along these lines, we have some concrete 
plans: 

Dealing with Inequalities: It would be nice to have a rational-like tactic 
to reason about inequalities in ordered structures. 



8 Related Work 

The Coq system is distributed with a basic standard library. There is quite some 
duplication between what one finds there and what we offer in C-CoRN. 

In particular the theory of real numbers by Micaela Mayero [27] is part of the 
standard library. This duplication extends to the tactics: what there is called the 
field tactic is the rational tactic in C-CoRN. However, the two theories of 
real numbers are quite different. Mayero’s reals are classical and based on a set 
of axioms that constructively cannot be satisfied, while the C-CoRN reals are 
constructive and also have various concrete implementations. Another difference 
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is that in the Mayero reals division is a total function which is always defined 
(although it is unspecified what happens when one divides by 0), which is not an 
option in a constructive setting. In C-CoRN, division can only be written when 
one knows that the denominator is apart from 0. This means that it gets three 
arguments, of which the third is a proof of this apartness. This difference also 
shows in the tactics field and rational. The first generates proof obligations 
about denominators, while the second does not need to do this, because this 
information already is available in the terms. 

Besides the standard library, all significant Coq formalizations are collected in 
an archive of contributions. From the point of view of the Coq project, C-CoRN 
is just one of these contributions, although it is currently a considerable part of 
this archive. The contributions of Coq have hardly any relation to each other. 
There is no effort to integrate the Coq contributions into a whole, like we tried 
to do with the C-CoRN library. Everyone uses the standard library, but hardly 
anyone uses any of the other contributions. 

Apart from Coq [13], there are several other systems for formalization of 
mathematics that have a serious library. The most important of these are: 
Mizar [28], HOL98 [33] and HOL Light [24], Isabelle/Isar [30], NuPRL/Meta- 
PRL [12] and PVS [31]. (Other systems for formalization of mathematics, like 
for instance Theorema [5] and Omega [32], do not have large libraries.) 

The largest library of formalized mathematics in the world is the library of 
the Mizar system, which is called Mizar Mathematical Library or MML. To give 
an idea of the size of this library: the source of the C-CoRN repository is about 2 
Mb, the sources of the Coq standard library together with the Coq contributions 
are about 25 Mb, while the source of MML is about 55 Mb. (Of course these 
sizes are not completely meaningful, as a Coq encoding of a proof probably has a 
different length from a Mizar encoding of the same proof. Still it is an indication 
of the relative sizes of the libraries of both systems.) 

Some of the theorems that are the highlights of C-CoRN are also proved in 
MML, like the Fundamental Theorem of Algebra and the Fundamental Theorem 
of Calculus. 

Unlike the Coq contributions, the MML is integrated into a whole: all Mizar 
articles use all the other articles that are available. So our goals with C-CoRN 
are similar to that of MML. However, there also are some differences. First, 
the MML is classical, while almost all of C-CoRN currently is constructive. 
More importantly, although the MML is revised all the time to make it more 
coherent mathematically, until recently theorems were never moved. In C-CoRN 
related theorems are in the same file, but in MML a theorem could potentially be 
found anywhere. Recently the Encyclopedia of Mathematics in Mizar project (or 
EMM) has been started to improve this situation, but it is still in an early stage. 
Another difference is that in C-CoRN arithmetic is formalized in an abstract 
style, as discussed above. In the MML both the abstract and concrete styles are 
available, but the majority of the formalizations use the latter. 

Mizar users are encouraged to submit their formalizations to the MML. Mizar 
is not designed to allow large libraries that are separate from the MML: the 
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performance of the system degrades if one tries to do this. When Mizar users 
submit their work to MML they sign a form to give up the copyright to their 
work, so that it can be revised if necessary by the Mizar developers. An approach 
on how to integrate work by others into C-CoRN still has to be developed. It 
will need to address the issues that (1) we want to encourage people who develop 
libraries on top of C-CoRN to integrate them into it and (2) we want everyone 
to be able to revise other people’s work without getting conflicts over this. This 
was discussed more extensively on page 96. 

The other systems mentioned above have a library similar to that of Coq. 
These libraries also have similarities to the C-CoRN library. For instance, in the 
HOL Light library both the Fundamental Theorem of Algebra and the Funda- 
mental Theorem of Calculus are proved. The Isabelle, NuPRL and PVS libraries 
also contain proofs of the Fundamental Theorem of Calculus. A comparison be- 
tween these proofs and the one in C-CoRN can be found in [14]. 
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Abstract. In this paper we describe the semantic analysis of differen- 
tial equations given in the ubiquitous formats MathML and OpenMath. 
The analysis is integrated in a deployed Web indexing framework. Start- 
ing from basic classifications for differential equations the proposed sys- 
tem architecture is amenable to extensions for further reconstruction of 
mathematical content on the Web. The syntactic analysis of mathemati- 
cal formulae given in the considered formats must overcome ambiguities 
that stem from the fact that formula particles may have different en- 
codings, which are in principle completely arbitrary. However, it turns 
out that the syntactic analysis can be done straightforward given some 
natural heuristic assumptions. 



1 Introduction 

The motivation [15] for this work stems from several tasks we have been dealing 
with during recent years. We are working in the field of computer algebra, a 
community that has substantially contributed to the definition of mathemati- 
cal encodings like MathML [13] or OpenMath [16]. We are also working in the 
Math-Net project [14], which collects mathematical information worldwide and 
tries to provide mathematicians with high quality information on mathematical 
subjects. Beside information on the organizational structure of the mathematical 
institutes, preprints and other papers on the Web are collected and analyzed to 
extract relevant information. Since MathML and OpenMath have gained wide 
acceptance by institutions like W3C and software manufacturers, it can be ex- 
pected that documents will use these encodings for formulae to a larger extent. 

An important detail is that MathML comes in two different styles, called Pre- 
sentation Markup and Content Markup. The latter describes the mathematical 
content of an expression, whereas the first defines the rendering of the expres- 
sion. Hence this widely used style does not contain rich information about the 
mathematical meaning. 

We have started to reconstruct mathematical content from formulae given 
in MathML and OpenMath with the concrete problem of analyzing differential 
equations. 
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Our current implementation supports the following orthogonal classifications: 

— order 

— ordinary vs. partial 

— linear vs. non-linear 

— homogeneous vs. non-homogeneous 

Modeling with differential equations is common in science. Therefore, if a 
researcher looks at a collection of mathematical papers the information on the 
type of differential equations used therein is interesting for him or her. The 
information may support the researcher with respect to his or her own modeling 
and may lead to methods for solving considered problems. A typical example 
is Drach’s differential equation. This is not well-known even among researchers 
in the field. An application for our approach could be to find all occurrences of 
Drach’ equation in the mathematical literature. 

The paper proceeds as follows. Sect. 2 discusses the problems encountered in 
parsing MathML and OpenMath formulae. The several classifications of differen- 
tial equations are defined in a succinct declarative pseudo code style in Sect. 3. 
The architecture of the proposed implementation is described in Sect. 4. The 
paper finishes with a discussion on further work, related work, and a conclusion 
in Sects. 5, 6, and 7. 



2 Parsing MathML and OpenMath 

Problems arise in parsing formulae given in MathML and OpenMath formats, 
because different amount of semantic clarification is needed for the several for- 
mats prior to semantic processing. MathML comes along with two versions, 
i.e., MathML Content Markup and MathML Presentation Markup. Whereas 
MathML Content Markup and OpenMath are oriented towards meanings of for- 
mulae from the outset, MathML Presentation Markup is designed for the task of 
rendering formulae. Therefore, if targeting semantic analysis eventually, parsing 
MathML Presentation Markup poses significantly more problems. 

2.1 MathML Presentation Markup 

In general the several possible particles of a formula have arbitrary appropriate 
encodings in MathML Presentation Markup ~ an encoding is appropriate as long 
as the intended visualization is achieved. Fortunately, it is possible to assume 
that the vast majority of MathML Presentation Markup documents found on 
the Web is not directly written or edited by the authors, but produced with one 
of the ubiquitous mathematical software tools, i.e. Maple [12], Mathematica [18], 
or WebEQ [4]. Therefore, the problem of ambiguity boils down to a thorough 
analysis of the common tools’ encodings of formula particles. Furthermore the 
MathML Presentation Markup standard [13] makes a couple of recommendations 
on how to encode certain constructs and, fortunately, the common tools more 
or less adhere to these recommendations. We delve into the topics of encoding 
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derivatives, characters, and operator and function applications. Table 1 summa- 
rizes the encodings yielded by the three leading mathematical software tools. 



Encoding of Derivatives. There are two well-known presentations for deriva- 
tives in mathematical ad-hoc notation. Accordingly, the MathML standard pro- 
poses two different Presentation Markup encodings of derivatives. For example, 
the non-partial derivative of a function / can be written in the following two 
ways: 

/' ( 1 ) 



d 
dx 

The MathML Presentation Markup encoding for (1) is the following: 

<mrow> 

<msup> 

<mi> f </mi> 

<mo> ′ </mo> 

</msup> 

</mrow> 

The MathML Presentation Markup encoding for (2) is the following: 

<mrow> 

<mf rac> 

<mo> ftDifferentialD; </mo> 

<mrow> 

<mo> &DifferentialD; </mo> 

<mi> X </mi> 

</mrow> 

</mfrac> 

<mi> f </mi> 

</mrow> 



(2) 



Character Encoding. Unicode characters or entities can be used to encode 
the same character. For example, the prime character in (1) is encoded by a 
Unicode character: 

<mo> ′ </mo> 

However, an alternative encoding for this is the following: 

<mo> ’ </mo> 

The problem to deal with many encodings for the same symbol is not difficult. 
The various encodings just have to be reflected by the grammar. The problem 
is rather to be aware of all possible encodings of a symbol. An allied problem 
is described in Sect. 4.1: a symbol with a predefined meaning may give rise to 
unsolvable ambiguity if it is not used with the intended meaning by the formula’s 
author. 
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Operator and Function Application. It makes a difference whether the pro- 
duced MathML code contains invisible operators or not. Invisible elements can 
affect the appearance of the formula in browsers and may prevent ambiguity. 
Consider the following MathML code fragment: 

<mi>x</mi> 

<mi>y</mi> 

Tools may visualize this code fragment as xy. However, it is not clear which 
of the following meanings the author has had in mind in writing this fragment: 

— X X y 

— X Ay 

— x{y) 

The ambiguity of just sequencing the variables x and y can be overcome, if 
the MathML invisible operators InvisibleTimes or applyFunction are utilized. 
Inserting one of these elements explicitly between the identifiers x and y makes 
the meaning obvious. Even bracketing for function application cannot always 
adequately replace the utilization of invisible elements. Though f{x, y) is un- 
likely to encode something different than the application oi f to x and y, the 
formula f{x + 1) still can have two different meanings, i.e. the application of / 
to a; -I- 1 or otherwise the multiplication / x (a; -I- 1). Unfortunately, the tools 
Mathematica [18] and WebEQ do not enforce the production of necessary invis- 
ible operators. Therefore heuristics must be employed in parsing operator and 
function application, e.g. based on the assumption that certain names are rather 
used as function names than basic variable names and vice versa. 

Table 1. Different encodings of formula particles by different formulae editing tools 



Encoding 


Maple 


Mathematica 


WebEQ 


derivatives 
character encoding 
multiplication 
function application 


mfrac 

entity 

explicitly 

explicitly 


mfrac/msup 

Unicode 

explicitly / sequencing 
explicitly/bracketing 


mfrac/msup 

Unicode/entity 

sequencing 

explicitly / sequencing/bracketing 



2.2 MathML Content Markup and OpenMath 

MathML Content Markup focuses on the mathematical semantics of formulae. 
With Content Markup it is easy to distinguish whether fx means f{x) or f * x, 
which makes the analysis of the formula much easier for our purposes. However, 
it is common sense that only a too limited subset of mathematical notation is 
covered by MathML Content Markup by itself. Therefore the csymbol element, 
which is available since the MathML version 2.0, allows Content Markup to 
embed elements from other notations, e.g. from OpenMath or Mathematica. 
In such a case heuristics must be used to find out which element is actually 
meant. Another problem is that MathML Presentation Markup and Content 





108 



D. Draheim et al. 



Markup are often connected in so-called mixed or parallel markup. This way both 
rendering aspects and mathematical content are included in the representation of 
a formula. Again MathML Content Markup comes in different dialects depending 
on the producing tool. 

OpenMath is an alternative for the encoding of mathematical formulae that 
is older than MathML and attempts to solve the problem in a much more rig- 
orous way than MathML. OpenMath is strictly content oriented and enables 
semantically rich encodings. Each object that is used in an OpenMath encoding 
includes a reference to a content dictionary, which is a mathematical definition 
of the object. For example, the operator plus used in different rings refers to 
different objects in separate OpenMath content dictionaries. Thus we have to 
integrate content dictionaries into the parsing process. Content dictionaries are 
created and collected by the OpenMath Society. 

3 Supported Classifications of Differential Equations 

The supported classifications of differential equations encompass the order of an 
equation, the question whether an equation is ordinary or partial, whether it 
is linear, and whether it is homogeneous. A succinct definition of these classifi- 
cations is provided in Fig. 1. Ad-hoc abstract syntax notation and declarative 
notation is used for this purpose. In the abstract syntax definitions all items are 
non-terminals. In particular, we do not specify the set of variables var and the 
set of operations op. 

Note that the actual LISP code for the classification used in the implemen- 
tation of our approach ~ see Sect. 4 - is, in effect not more complex than the 
declarative definitions given in Fig. 1. For the purpose of analyzing a differential 
equation an equation is simply a term composed of variables, operations, and 
derivatives. A derivative consists of the target function name and the derivate 
variables. The list of derivate variables may be empty, this way representing 
the genuine occurrence of the equation’s target function. For the definition of 
linearity it can be assumed that the differential equation adheres to the com- 
mon sum-of-product normal form, expressed by the abstract syntax notation 
normalized. Furthermore it can be assumed that the differential equation’s tar- 
get function is unique. In our implementation these assumptions hold because 
of the employed computer algebra stage and verifier stage. The homogeneity of 
a differential equation can be specified syntactically without detouring. 

4 Solution System Architecture 

Separation of concerns leads to a straightforward compiler stage architecture 
for the solution system, see Fig. 2. After finding a formula encoded in MathML 
or OpenMath it is parsed and an abstract syntax tree is built. We have used 
ANTLR [17] to build the parser. Printing the abstract syntax tree yields the for- 
mula in LISP format. If the formula represents a supported differential equation 
it is further processed by the REDUCE [8] computer algebra system and the 




Classifying Differential Equations on the Web 



109 



derivative ::= var var* 
equation ;:= var 

I derivative 

I op equationi . . . equation^ 



order : equation N 



fo 



, DEF 

order eq = 



< 



n 

max IJ order eqi 

l<i<n 



, eq € var 

) eq — f vi . . .Vn £ derivative 
, eq = op eqi ... eq„ 



derivations : equation 2 ”“’’ 

{ 0 , eq £ var 

{ui . . . u„} , eq = f vi,...Vn,£ derivative 

U derivations eqi , eq — op eqi . . . eq„ 

l<i<n 



ordinary : equation B 
partial : equation — » B 

ordinary eq \derivations eq\ = l 

partial eq -■ ordinary eq 



normalized ::= (equation? derivative?)* 
linear : normalized B 

linear eqi (/ varsi) . . . eq„ (/ varsn) ”= V / ^ eqi 

l<i<n 

homogeneous :;= (equation? derivative)* 



Fig. 1. Definition of the supported classification of differential equations. Non-terminals 
of the abstract syntax are used in the declarative definitions in bold face in order to 
denote the respective syntactic categories 



formula is transformed into a normal form. Afterwards LISP programs classify 
the formula. The result of the classification is printed out in Summary Object 
Interchange Format (SOIF) because the classification is embedded into the Har- 
vest system [1, 11], which uses SOIF data for its internal information storage and 
exchange. 

The proposed solution is scalable with respect to functionality in several 
means. Future formats can be integrated easily - the abstract syntax serves as a 
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MathML PresentatiotO <C MathML Content 



OpenMath 



Heuristic ANTLR Parser 



Abstract Syntax T ree 






LISP formula 



Verifier 



0 



SOIF classification 



REDUCE 



C jiSP normalized formula 

-a- 



LISP classifier 



classification 



Fig. 2. The compiler stages of the differential equation classifier 

mediator between different formats. Because of the computer algebra stage the 
software system is prepared for projected advanced semantic analysis. 

4.1 Parsing Problems 

First of all we assume that the MathML and OpenMath code under consider- 
ation are syntactically correct. Thus we specified non- validating grammars to 
reconstruct the content of the represented formulae. Parsing is aborted if it can 
be recognized lexically that the considered formula is actually no differential 
equation, for example, because it encompasses elements for encoding integrals 
or matrices. We cannot assume that the rules for the so-called proper grouping 
in Sect. 3.3 of [13] are always followed. Thus unnecessary mrow elements are es- 
caped. Unnecessary mrow elements are those which are not nested within other 
elements, e.g., mfrac or msup elements. Only attributes relevant to differential 
equations are recognized. 

The Presentation Markup grammar needs to distinguish between two kinds 
of identifiers, i.e., monad operators and simple variables. If an ambiguity oc- 
curs our heuristic solution decides in favor of the monad operator. For exam- 
ple, <mi> sin </mi> always represents the sinus function even if there is no 
applyFunction element next to it. 
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A differential equation consists of variables, numbers, differential quotients, 
and functions, which are bound by operators. In MathML Content Markup and 
OpenMath the grammar has just to follow the apply structure of the formula in 
order to reconstruct it. However, with respect to the actual operator structure 
parsing a formula encoded in MathML Presentation Markup is more complicated 
because the grammar has to define several internal levels to correctly obtain the 
priority of arithmetical operations. 

4.2 Further Processing 

After parsing a verifier checks whether a given formula actually can be considered 
a proper differential equation. For example, it is checked whether the target 
function is unique across all the equation’s derivatives. If the target function 
is not unique the equation stems perhaps from a differential equation system, 
may be interesting, but not amenable to the classifications examined in this 
paper. 

For the purpose to store the result in a unified format, the intermediate 
result is processed with computer algebra methods. Simplification rules are ap- 
plied and a normal form is achieved. The processing identifies dependent and 
independent variables. As a result the derivatives and the target function are fac- 
tored out so that the analysis of linearity and degree are simplified. REDUCE 
has been the computer algebra system of choice because it is a proven system 
and because REDUCE formulae can be denoted by LISP S-expressions. ANTLR 
generated parsers build abstract syntax trees as two dimensional presentation of 
the formula that can be printed out as LISP S-expressions and can be forwarded 
directly to REDUCE. 

4.3 Integration into Harvest 

The resulting classifier is embedded into an instance of the Harvest system - see 
Fig. 3 - that is hosted by the Math-Net project. Harvest is a distributed search 
system; the main components of Harvest are the gatherer and the broker. The 
gatherer collects and summarizes the resources on the Web. The broker indexes 
the collected information and answers queries via a Web interface. Gatherer and 
broker communicate using an attribute-value stream protocol, the proprietary 
SOIF. The gatherer triggers different summarizers for different kinds of docu- 
ments. The available set of summarizers neither supports MathML nor Open- 
Math resources. We provided appropriate new summarizers for these resources 
- MathML can be found on the Web in XML files explicitly tagged as MathML 
or in XML files; OpenMath can be found in XML files. 

5 Further Work 

Currently we are working on the integration of a general formula search facility 
into our system. The problem of searching formulae, i.e., querying for formulae 
that match a given target formula, is different from querying formulae that match 
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Fig. 3. Integration of the differential equation classifier as a summarizer into the Har- 
vest system 



given classification options. A merely textual approach for searching formulae 
is obviously not sufficient. Therefore each approach for searching formulae must 
fix a notion of similarity between formulae. Different degrees of similarity are 
conceivable. At a very basic level one wants to consider equivalent formulae as 
equal. Similarly formulae should be considered equal up to renaming of variables. 
However, more sophisticated similarities between formulae might be of interest. 
For example, two formulae are similar, if they can be constructed from each other 
by general term rewriting. However, subtle pragmatic questions now arise that 
can only be resolved by heuristic decisions: what is the appropriate granularity 
of term substitutions? Should it be possible to search for instances of a target 
formula? Or should it rather be possible to search for generalizations of a target 
formula? 

A great deal of work with respect to questions like these has been done 
in the SearchFor project [3] at the INRIA Sophia-Antipolis Research Center. 
We are trying to utilize the results of the SearchFor system in our project. In 
principle, there are two basic approaches to this. In the brute force approach a 
converter from the S-expression format to the CAML data structure format is 
developed so that the SearchFor code can be reused operatively. In the reverse 
engineering approach the CAML code of the SearchFor system is investigated 
and reimplemented in LISP code. 

Furthermore it would be interesting to fix formal semantics for notions of 
similarity between formulae. Again the knowledge about formula similarity con- 
struction that is encapsulated in the SearchFor system could serve as a corner- 
stone for this work. 
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Based on a facility for searching formulae it would be neat to offer search 
options for well-known differential equations or differential equation patterns, 
like Abel’s differential equation, the Bernoulli differential equation etc. 

6 Related Work 

In [9] a PROLOG-based document object model for XML documents is pro- 
posed. Transforming XML data into the so-called field notation results in an 
expert system against which rule-based queries can be executed. The approach 
is elaborated for XML documents in general and is applied to the concrete for- 
mats MathML Content Markup and OpenMath in particular. Furthermore [9] 
outlines the application of the approach to the classification of ordinary dif- 
ferential equations with respect to Kamke’s list [10]. The notion of rule-based 
expert system has gained remarkable consideration in the eighties for building 
and exploiting knowledge bases - today’s working knowledge base mining relies 
on statistical modeling methods rather than on proof theory. However, in the 
case of processing mathematical knowledge it is promising to employ a logical 
programming language, because term rewriting problems that typically occur 
can be tackled by the logical programming languages’ unification mechanisms. 
Other approaches that employ logic programming language techniques for math- 
ematical knowledge bases are described in [2] and [6,7]. 

A similar approach was used in the TILU [5] project by Einwohner and Fate- 
man. This project provides an alternative to algorithmic integration algorithms 
by integral table lookup. Special conditions which arise often in integration prob- 
lems, e.g., special functions in the integrand, can be used to optimize the search 
of the formulae. 



7 Conclusion 

We expose the following assumptions and observations: 

— The Web is a huge repository; this is particularly true for mathematical 
knowledge. 

— Sophisticated search capabilities for mathematical Web resources are re- 
quired by research and education. 

— MathML and OpenMath can be expected to become de-facto standards for 
mathematical Web resources. 

— Subtle notation issues arise in handling MathML and OpenMath. 

We have undertaken the following steps: 

— We have chosen the classification of differential equations as a challenging 
starting point of our project. 

— Due to its separation of concerns, the chosen system architecture is scalable 
with respect to further formats and further classifications. 
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~ The implementation is used in a working instance of the Web indexing frame- 
work Harvest. 

It is further work to integrate a general formula search facility into our 
approach. 
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Abstract. The problem of the integrity of a computer managed math- 
ematical knowledge repository is in the heart of MKM since mathemat- 
ical vernacular is a language permitting plenty of ways in expressing the 
same meaning. The users of the library are naturally forced to choose 
certain way among many similar ones, unless different approaches are 
provided by developers. Mizar is a system for formalizing mathematical 
content which is sufficient mature and flexible for a coexistence of dif- 
ferent approaches of concrete subjects. Considering Mizar formalizations 
of ortholattice theory we discuss a useful mechanism of coping with the 
heterogeneity of theories in a library of mathematical facts. 



1 Introduction 

One of the questions which occur during planning and building of mathematical 
knowledge repositories is: should be the system centralized or rather distributed? 
Both approaches are tested and more or less successfully used in the field which is 
in the core of MKM. On the one hand, distributed, not necessarily homogeneous 
network of systems specialized in the different disciplines (e.g. theorem provers, 
model searchers, proof checkers, user interfaces etc.) together with appropriate 
broker architecture seems to offer a broader, more efficient structure for a math- 
ematician to work with - from a bright idea until the successful submission of 
his/her work for publication. 

But if we restrict our considerings to one part of mathematical activity only - 
e.g. to developing and enhancing of the computer checked repository of formal- 
ized mathematical knowledge, we may find the broad system ineffective and 
hard to use, especially if a significant part of the system lifetime is spent on a 
communication/translating from one standard to another. We still need efficient 
techniques to make larger systems work more smoothly than we may to observe 
nowadays. 

In the paper [19] presented at the MKM 2003 in Bertinoro, important ques- 
tions were formulated: what exactly means the integrity of a repository, how to 
deal with a library to make it (more) homogeneous. We want to shed some light 
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onto another side: what mechanisms are sufficiently feasible to enable different 
approaches to the same problem or other formulations of the similar notions. 
Obviously, in any sense it does not mean that the repository should contain all 
approaches available in the literature. The computer can serve here as a kind of 
Kerberos which will not accept badly formulated, illogical notions (compare [3]). 

Some people within MKM community (mainly not those ones who work hard 
introducing new standards) believe that an ordinary user of a mathematical 
service should not be forced to use a notion/ an approach against his personal 
preferences. Should he change them? Or should he abandon the service? None 
of the solutions seem to be satisfactory here. 

It may be observed that a few problems are the decisive barriers for the use 
of computer-managed repositories by a pen-and-paper scientist. First, too much 
formalism is usually strongly avoided - formal or even just rigorous mathematics 
seems to be a pain in the neck for an ordinary mathematician. The notion of 
a formal proof sketch proposed by Wiedijk in [22] may be a kind of solution. 
Another main problem is search and retrieval of knowledge. Here we can point 
out the quality of a searching tool as well as the organization of the library. 
We can also accent - last but not least - the heterogeneity of approaches to 
the chosen notion. If the author prefers e.g. certain axiomatics (even if logically 
equivalent to a classical base), a constraint of using another one would be a 
serious drawback. 

In this paper we describe some of the issues concerning the formalization of 
ortholattices based on the lattice theory formalized in the Mizar Mathemati- 
cal Library (MML for short - see [14]). We propose also a new, heterogeneous 
approach to the lattice theory in one of the largest libraries of (proven!) mathe- 
matical facts. The structure of the paper is as follows. In the next three sections 
we give an outline of the theory of lattices, posets, and ortholattices formalized 
in MML. In the fifth section we discuss heterogeneous approaches to considered 
theories. At the end we present related work and draw some final remarks. 



2 Classical Formalization of Lattices 

As the primary aim of the formalization of lattices project were Boolean algebras, 
let us see for the description of lattices in MML from this perspective. Since the 
notion of a structure is fundamental to understand abstract mathematics (as 
defined in [18]), we assume basic knowledge of Mizar structures and selectors, 
thorough exposition of the topic and an overview of the Mizar type system can 
be find in [1]. 

According to the classical definition. Boolean algebras are 6-tuples of the 
form {B, V, A, ' , 0, 1), where V, A are binary operations in H, ' is a function from 
B into B and 0, 1 are two distinct elements of B. The axiomatics concerned with 
it is well known. The structures in Mizar are implemented as partial functions on 
selectors, which make e.g. merging structures more natural. Considering struc- 
tures as ordered tuples, one might face the problem with merging operation, 
because catenation of sequences will not work properly. 
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Fig. 1. The net of structures for lattice theory 



Dependencies between underlying structures may be visualized as in Fig. 1. 
Arrows describe inheritance relation for selectors (fields of the structures). As 
it may be concluded, the backbone structure for almost all MML structures 
is 1-sorted and all considered structures in the paper are descendants of it. 
Some of the objects have only one prefix (an ancestor) - in that case additional 
selectors are given. All others from the figure (besides 1-sorted) act as items 
inheriting selector information. The number of multiprefixed structures in MML 
is relatively high (22 out of 91). Essentially structures play a role of signatures for 
domains. The definition of a structure provides only the typing data for operators 
(selectors). This information is enriched by the use of adjectives which will be 
explained in more detail later in the paper. Unfortunately, a user cannot define 
synonyms for selectors and structure names, i.e. upper and lower semilattice 
structures are defined separately, as well as corresponding notions. Hopefully, it 
will be reimplemented by the Mizar developers. 

Even if synonyms for structures still cannot be defined, we may try to solve 
the problems concerned with it in a different way, thanks to the heterogeneous 
algebraic hierarchy, as we did in the case of the most famous questions answered 
with a help of an automated theorem prover. 

In the early thirties of the previous century, Robbins posed the question if 
the equation which is a variant of one of the Huntington’s axioms for Boolean 
algebras of the form 

((a + b)' + (a + b')')' = a, 

where a,b are arbitrary elements of the abstract algebra (L,+, ') together with 
the commutativity and associativity still form a basis for the variety of Boolean 
algebras. For sixty years researchers could not find the answer to this question. 
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After McCune’s solution of the Robbins problem [13] (that is, after proving 
that all Robbins algebras are Boolean), we decided to reuse existing formal 
apparatus for lattices and test the flexibility of this approach. The details of the 
experiment can be And in [9]. 

The choice of the appropriate structure was not straightforward. At a first 
glance, we might reuse developments from the algebraic ring theory. We wanted 
however to be as close as possible to Huntington’s original paper where the un- 
derlying structure was (5, V, '). Moreover, intensive work with formalization 
of [2] (nearly 60 Mizar articles and numerous revisions of MML) made lattice 
theory developed in Mizar more suitable to further reuse. As a side-effect we en- 
coded also a problem of a single axiom for Boolean algebras in terms of negation 
and disjunction and its 2-ax;iomatization due to Meredith. 

We cite as an example the definition of a structure with signature (2,2,1) 
which may be treated as a skeleton of an ortholattice. It is prefixed by the 
lattice and structure with a complement operation. 

struct (ComplLattStr , LattStr) OrthoLattStr 
(# carrier -> set, 

L_join, L_meet -> BinDp of the carrier, 

Compl -> UnOp of the carrier #) ; 

The ComplLattStr has been introduced to keep defined notions and theorems 
at a satisfactory level of generality. It has two antecedents: upper semilattice - 
from which L_join is inherited, and a structure with a complement operation 
represented by the which field Compl. The carrier is inherited from both struc- 
tures. For this structure the definition of the Robbins axiom seems to be very 
natural. 

definition let L be non empty ComplLattStr; 

attr L is Robbins means :: ROBBINSl:def 5 

for X, y being Element of L holds 
((x + y)‘ + (x + y‘)‘)‘ = x; 

end; 

Actually, “+” is introduced as a synonymous notation for the lattice supre- 
mum operation, because it is simply shorter and easier to type. Unfortunately 
we could not use because it is reserved for an identifier, so is used in- 
stead. The attribute de_Morgctn defines a natural connection (de Morgan laws) 
between join, meet, and complement operations. 

definition let L be non empty OrthoLattStr; 

attr L is de_Morgan means :: RDBBINSlidef 23 

for X, y being Element of L holds x "/\" y = (x‘ "\/" y‘)‘; 

end; 

Because from the Mizar structure definition only information about the arity 
and the type of the result on arguments of selectors can be obtained, we are forced 
to introduce the following attribute to ensure that the selector corresponding to 
the unary complement operation has actually all properties of the complement. 
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definition let L be non empty OrthoLattStr ; 

attr L is well-complemented means :: RQBBINSl:def 10 
for a being Element of L holds 
a‘ is_a_complement_of a; 

end; 

Table 1 summarizes used structures together with the names of the intro- 
duced new selectors (second column) together with their mother type (third 
column). It is easily seen which items do not introduce any new selectors. In the 
fourth column we give some of the adjectives defined for the appropriate struc- 
ture. Inheritance mechanisms implemented in Mizar verifier allow for applying 
such attributes in all descendant structures. Since the adjective “Boolean” is 
only a shorthand for a list of some other adjectives, it is not included in the 
table. 



Table 1. Basic types used in the formalization 



Structure 


New selector 


Type of introduced selector 


Attribute 


1-sort ed 


carrier 


set 


non empty 


ComplStr 


Compl 


UnOp of the carrier 




V-SemiLattStr 


LJoin 


BinOp of the carrier 


join-commutative 

join-associative 

join-idempotent 

upper-bounded 


A-SemiLattStr 


L_meet 


BinOp of the carrier 


meet-commut at i ve 
meet-associative 
meet-idempotent 
lower-bounded 


LattStr 


none 


n/a 


join-absorbing 

meet-absorbing 

distributive 


ComplLattStr 


none 


n/a 


Robbins 

satisfying_DN_l 


OrthoLattStr 


none 


n/a 


de_Morgan 



Now the partial correspondence between newly introduced Robbins and pre- 
viously defined in MML Boolean algebras can be shown for lattices in the form of 
the conditional cluster registration which is cited below. Obviously, to visualize 
full equivalence of these algebras, the second implication should be also written 
with its rather straightforward proof that the Robbins equation is true in all 
BAs. 

registration 

cluster Robbins join-associative join-commutative de_Morgan -> 

Boolean (non empty OrthoLattStr) ; 

end; 
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The OrthoLattStr ensures that all the attributes (with “Boolean” at the top) 
for LattStr can be used. It can be read (and in fact is translated automatically) 
in natural language as “every lattice structure with associative and commutative 
join operation which satisfies Robbins axiom is also Boolean.” 



3 Orderings as an Alternative 

From the mathematical point of view, an alternative approach for lattices, i.e. 
posets which have unique binary suprema and infima operations, is clearer and 
used even more often nowadays. What is especially important, it provides more 
homogeneous view for the theory as a whole since orderings present more general 
way to handle lattices, e.g. if we dropped some of the attributes of the internal 
relation. 

Stepping from posets to lattices is done via “globalizing”: a lattice £ is a 
poset V = {P, < ) such that for arbitrary pair of elements of P its infimum and 
supremum exist in P; i.e.: 

ya;,y G p ^v,w eP V = inf{x, y} Aw = sup{x, y}. 

Then the binary lattice operations of join and meet get identified with supre- 
mum and infimum of the set of arguments. Henceforth the basic lattice laws of 
commutativity, associativity, idempotence, and absorption correspond directly 
with partial order properties; thus one can turn from posets to an algebra of type 
(2, 2). Such a transit is justified by the common notion of semantics: a succedent 
S follows from an antecedent A only if for all possible valuations val one has 
eval{val, A) < eval{val, S) (with respect to the underlying poset). 

Such an analogy (with logics) can be pursued furthermore. Bounds for a 
lattice may be introduced just mimicking the role of Boolean values as used in 
logics maximum T and minimum T; i.e.: Va,gpa;<T AT<x. Rewriting it 
into the lattice notation one gets a bounded lattice: 

Va;gpa;nT = xAxU± = x. 

The formal apparatus for relational structures introduced in MML looks that 
way: 

struct (1-sorted) RelStr (# carrier -> set, 

InternalRel -> Relation of the carrier #) ; 

mode LATTICE is with_infima with_suprema Poset; 

The adjective with_inf ima is slightly stronger than in the literature, i.e. it 
states for a relational structure L that infima exist for arbitrary finite non-empty 
subset of L, dually is with_suprema. The mode Poset is defined naturally as 
reflexive trauisitive antisymmetric RelStr. The name LATTICE was cho- 
sen not to overload Lattice with its meaning as defined in the previous section. 
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4 Ortholattices 

An antitone involution as already defined for “orthoposets” [15] gives way to 
some sort of relatively complemented lattice: 

'i X p = X A\/y(zp{x<y^y^<x’^)). 

Turning c into a pseudocomplement results in orthocomplementation: 

Va;gp xna;'^ = _LAa;Ua;'^ = T. 

Such a lattice (P, n,U,_L,T) is called orthocomplemented and bounded. One 
can observe that only one bound needs explicit assumption. 

Herewith all properties of orthocomplemented lattices have been stated. How- 
ever the antitonicity property of the orthocomplement is genuinely stated via 
order. An equivalent property in terms of lattice algebra are the de Morgan 
laws - with provision for the other properties; statement of one version suffices 
here: 

^x,ydP {.xUyY = x'^Uy'^. 

A lattice satisfying boundedness, orthocomplementation, and admission of 
de Morgan laws is called an ortholattice - short for orthocomplemented lattice 
[ 11 ]. 

As above lattices are accepted as structures of type (2,2, . . .). Yet its order 
properties come to the fore all too often. As ubiquitous examples we have: 

a) the set inclusion property is commonly used in set algebras (e.g. power set 
with set operations), 

b) in logics the validity of implications p q is defined via the order eval{p) < 
eval{q) with respect to the underlying algebraic semantics - lattice-like struc- 
tures in semantics are surely not endangered by extinction. 

Hence properties and (proof) argumentation are often based on order ar- 
guments. Usually join and meet operations are translated as supremum and 
infimum of its arguments - and vice versa. Whereby these notions get defined 
via order properties - especially when introduced on real numbers. 

Thus an approach via order is not only some alternative but frequently de- 
sired. Above pointer to the implication tells what basic properties are looked for: 
partial order and negation [8]. The join and the meet can be introduced later 
(e.g. for technical purposes). Bounds are additional properties (for each of the 
approaches) which do not interfere per se with structural matters. 

Henceforth basic structures should be equipped with relation and complemen- 
tation. That means partial order relations for this paper. After such clarification 
the technical analogon is introduced in Mizar [15]: the object OrthoRelStr. 

struct (RelStr, ComplStr) 

OrthoRelStr (# carrier -> set, 

InternalRel -> (Relation of the carrier) , 

Compl -> UnOp of the carrier #) ; 
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It is a successor of the already defined simple relational structure RelStr 
and the unary operator structure ComplStr ~ very general ancestors indeed. 
Such constructs refer to general structures O of the schema: 

O = (carrier, binary relation, unary operation). 

As explained in [18] this is only notion (or type in universal algebra) - prop- 
erties are overdue. 

There are already a lot of common relation properties in Mizar. Yet adoption 
of such notions is not that plain one would like; that was a reasonable aim for sake 
of reusability and compatibility. These notions are usually in strict formulation - 
the property holds only for a (proper) subset of the carrier. But fundamental 
poset notions are total ~ only total. With a little detour the partial order notion 
gets introduced as a shorthand: 

definition let 0 non empty OrthoRelStr; 

attr D is PartialOrdered means :: 0P0SET_l:def 25 
0 is reflexive antisymmetric transitive; 

end; 

A double negation property is wanted in matters of complementarity. Hence- 
forth an involution property is introduced by an appropriate attribute dneg for 
unary functions: 

attr 0 is Dneg means :: OPQSET_l:def 7 

ex f being map of 0,0 st f = the Compl of 0 & f is dneg; 

Because of the globalilty of the attribute it is defined via the special property 
of a constructor element. Thus the basic properties stated above get defined as 
simple combination: 

attr 0 is Pure means :: 0PDSET_l:def 27 

0 is Dneg PartialOrdered; 

Of course, this is only the skeleton of the necessary properties. Mizar demands 
existence proofs for new notions. Thus the need for simple structures with the 
desired properties arises. TrivPoset plays such a role throughout the subject: 

definition 

func TrivOrthoRelStr -> strict OrthoRelStr equals :: 0P0SET_l:def 5 
OrthoRelStr (# {{}■}, id ff}}-, opl #) ; 

end; 

where id {{}} is an identity map on {0}, i.e. a binary relation with only one 
element (a pair (0, 0)), hence nearly all properties (except a few like asymmetry) 
get trivial within. 

Order involutivity and boundedness are still missing as the completing ortho- 
poset ingredients. These orthocomplementarity and bound properties are defined 
in one step (for a unary operator on the carrier of a structure) : 
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definition let PO PartialDrdered (non empty OrthoRelStr) , 
f be UnOp of the carrier of PO ; 

pred f OrthoComplement_on PO means :: QPOSET_l:def 36 

f is Qrderinvolutive & for y being Element of PO holds 
ex_sup_of -[y,f.y},P0 & ex_inf_of -[y,f.y}-,P0 & 

"\/" ({y,f .y},P0) is_maximum_of the carrier of PO & 

"/\" ({y,f .y},PD) is_minimum_of the carrier of PO; 

end; 

where the used predicates are defined according to its names. 

Herewith the typical distinction between posets and lattices gets apparent: 
the existence of a supremum or infimum is not always assured - even not for 
bounded structures. The orthocomplementarity with PartialDrdered attribute 
suffice together for an orthoposet mode OrthoPoset. 

Thus the OrthoLattice mode takes a pathway around the OrthoPoset (the 
complete development is contained in [15, 10]): 

mode PreOrthoPoset is 

Order Involutive Pure (PartialOrdered (non empty OrthoRelStr)); 
mode PreOrthoLattice is with_infima with_suprema PreOrthoPoset; 
mode OrthoLattice is Orthocomplemented PreOrthoLattice; 

As already indicated “global” infimum and supremum (pair) properties are 
missing for the step towards an ortholattice mode. For conceptual (and practi- 
cal) reasons a detour was taken via order involution properties and subsequent 
addition of orthocomplementarity instead of merging join- and meet-semilattice 
properties. 



5 Handling Mnltiple Axiomatizations 

Why the problem of handling heterogeneous approaches is so important? Many 
mathematical problems are often based on different approaches to the same 
notion and an agent managing a uniform mathematical knowledge repository is 
often stuck with a plenty of those choices. Furthermore, there are mathematical 
results only establishing connections between them. Some of the recently solved 
examples are - mentioned in the second section - the Robbins problem and 
various short Sheffer-stroke axiomatizations of Boolean lattices. 

There are two main situations when dealing with multiple axiomatizations: 

~ different sets of operations, and consequently different structures and axioms 
(as Boolean posets comparing to Sheffer algebras); 

— the same structure, multiple sets of axioms (e.g. 1-axiomatization for Boolean 
algebras based on the Sheffer-stroke vs. classical Sheffer or Meredith bases). 

Regardless of the case a mutual recoding of the different theories is strongly 
needed. 

The attempts of translation between lattices and posets within MML are 
not new - as well as numerous examples of elimination equivalent or redundant 
notions to increase uniformity of the library [19]. 
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One of the existing - and rather not fully effective - approaches is developed 
in the Mizar article LATTICES^, via the Mizar functors establishing the commu- 
nication between RelStr and LattStr with appropriate parameter and result 
type as cited below. 

definition let L be Lattice; 

func LattPOSet L -> strict Poset equals :: LATTICES :def 2 
RelStr (# the carrier of L, LattRel L #) ; 

end; 

definition let A be RelStr such that 

A is with_suprema with_infima Poset; 

func latt A -> strict Lattice means :: LATTICE3:def 15 

the RelStr of A = LattPOSet it; 

end; 

If the theories have e.g. different axiomatizations but the underlying structure 
is the same, then a conditional clusters mechanism assures the proper commu- 
nication without interference from the user’s side (no reference for a cluster is 
needed). Otherwise the common platform has to be worked out. This is how the 
Robbins problem has been solved. 

Similarly, we have merged relational and lattice structures to obtain com- 
bined LattRelStr and introduced an adjective assured that the ordering and 
suprema/infima generate each other. 

definition let L be non empty LattRelStr; 

attr L is naturally_sup-ordered means 
for X, y being Element of L holds 
X <= y iff X " LI " y = y; 

end; 

The synonymous symbol " I _ I " has been declared to cope with overloading 
of the symbol "\/". Authors introducing the supremum induced by a selector 
in LattStr and those using the same symbol for operation determined by the 
ordering in relational structure do not anticipate that the overloading will be 
dangerous since these objects have never been merged. 

Now naturally_sup-ordered Lattice-like (non empty LattRelStr) can 
be a common type which may be used for further development of ortholattices 
(but equivalence of poset and lattice approach cannot be given in general as 
written in Section 4), Boolean algebras etc., both in binary meaning and via 
orthoposet. Inheritance will be crucial to use it properly. Conditional clusters 
also work to automatically obtain that the object with the type as above has 
the proper result type. 

The historical motivation standing behind the approach described above is 
that there is a rich formal apparatus developed around binary lattices. We 



^ Mizar articles can be browsed at the Journal of Formalized Mathematics section 
in [14], the MML identifier is important here. One can find there all articles from 
Formalized Mathematics, however in their continuously revised form. 
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wanted to reuse it. But what to do if an author does not think about heterogene- 
ity (as it often happens)? Revise the existing state? Or better rewrite everything 
from scratch? As it may be concluded from an experiment of Encyclopedia of 
Mathematics in Mizar, it is easy to be trapped by the infinite generalizations 
loop. EMM covers complex algebra of sets, complex numbers, and beginnings of 
reals, and then stopped. 

The Library Committee of the Association of Mizar Users prefers a policy of 
continuous evolution rather than revolutionary building fragments of the library 
from scratch. On the one hand, the authors’ rights should not be violated (while 
the language and library evolves, they can hardly recognize their works, how- 
ever). They sign a copyright form and the Committee has the right to change 
their articles. 



6 Related Work 

The number of obstacles which authors of a knowledge repository may meet, is 
not so serious when the whole library is carefully designed by a small number of 
developers. That is the position of C-CoRN [5] at the moment (the number of its 
authors is around ten times less). Apart from that its foundations differ. Proofs 
in Coq are constructive compared to classical ones in Mizar. The philosophy 
of Coq is also different than that of the Mizar checker. The Constructive Coq 
Repository at Nijmegen may benefit from MML experience. 

As an example of successful unification of primarily heterogeneous theories 
we can give also the recent redesign of the construction of complex numbers 
in MML. Originally defined in Mizar as pairs of real numbers, there were no 
way to force Mizar analyzer to understand e.g. complex zero as a real number, 
unless we use a casting function to provide a new type for a given variable. 
A new construction of reals from complex numbers with empty imaginary part 
together with cluster of attributes mechanism allow to clear the library and to 
remove some casting functions. The previous idea of the set of complex numbers 
C as a Cartesian square of set of reals seems to be satisfactory in a standalone 
version. However, if we require to have a natural injection of reals into the set 
of complex numbers without any dirty hacks, we may face serious obstacles. 
The same problem occurs obviously also in the case of a construction of integer 
numbers from naturals etc. In the case of classical mathematics, not the abstract 
one (where by the classical mathematics we understand this which does not use 
the notion of a structure, so here structure mechanisms obviously will not work), 
we can say about a uniformization process rather than about development of a 
heterogeneous theory. 

Examples in group, field theory etc. arise many hard decisions: e.g. whether 
to introduce complement or unit element as a selector in a structure or to define 
it by adjectives? Even if causing many ambiguous situations, adjectives are very 
efficient and create with their expressive power an exclusive feature of the Mizar 
system. 
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The inheritance of theories is implemented in most systems which have their 
libraries. E.g. in Isabelle/HOL [16] theory Lattice is successor of the theory 
Bounds in similar manner as in Mizar [21]. 

axclass lattice C partial-order 
ex-inf: 3 inf. is-inf x y inf 
ex-sup: 3 sup. is-sup x y sup 

Category theory implemented in MML has pointed out that multiple fields 
need not be as feasible as it can be expected, and the attempt of uniformization 
failed because in fact there are no connections between the old (CAT) series and 
the new ones (ALTCAT for alternative category theory), they are still (and will 
be probably) developed independently. The other reason is that the approach 
with the structure with large number of selectors (maximum of ten in this case) 
seems to be inefficient. 

The freedom of choice among orderings and binary operations is important 
since equational reasoning is what many provers, e.g. EQP/Otter [9] are good 
at, and the usage of the ordering approach may decline prover’s help. What 
remains is the question how can we deal with the results found by EQP/Otter, 
how to translate untyped calculations into the reasoning extensively using Mizar 
type system. Josef Urban’s work [20] is promising, and in fact one can translate 
all Otter proof objects into a Mizar-like source code. Still you have to create 
appropriate data structure on your own. 

What is important is the data structure, because proofs can be converted 
more or less automatically, or justification can be assured thanks to the inheri- 
tance mechanism. If we are not interested in further reusing of the notions, we 
can leave this issue and develop the proofs at different stages for multiple no- 
tions. That is the way freshmen can work, if they have only a narrow view at a 
discipline they learn. The desired knowledge repository should however offer pos- 
sibly compact set of notions which enables the user via polymorphic mechanisms 
smooth retrieving of the appropriate workplace. 



7 Conclusions and Further Work 

The integrity of a computer managed repository of mathematical knowledge is 
important in the same degree as its distributivity or polymorphism. Considering 
integrity we have to take into account two issues: compatibility between different 
theories to avoid cost-consuming translations, and uniformity of the approach. 
Authors should have opportunity to freely choose between approaches and to 
communicate between all of them at all stages of their activity to enable smooth 
work and usage of formal apparatus which is more feasible at the chosen state. 

Tools which enable in our opinion comfortable work are structures and at- 
tributes. In the Mizar system a mechanism of structures could be much improved, 
e.g. to enable only formalization of lower semilattices and to obtain automat- 
ically the description of upper ones etc. Such a form of transformation would 
ease life by saving existence proofs without posing dangerous logical problems. 
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The more knowledge will be retrieved, the less time an author will spend on 
a usual copy-and-paste job, the more creativity will be freed. Modern projects 
like FDL [4] and FoC [17] pay attention to such “user-friendly” issues (not to 
forget inheritance issues). Although more oriented towards algorithmic knowl- 
edge representation such projects point at the weaknesses and needs of “pure” 
proof checkers like Mizar where usability is narrowed by lack of user support and 
information on dependencies could be used more widely. 

The experiments with heterogeneity of the approach to the lattice theory 
within MML are not finished since they have proven their usefulness and func- 
tionality. Using similar methods, we have developed a Boolean lattice theory in 
terms of the Sheffer stroke and prove its 1-axiomatization [12]. Although the 
structure based on the Sheffer stroke is completely different from the two de- 
scribed in Section 2 and 3, we successfully reused the existing formal apparatus 
for Boolean algebras benefitting from structures and clusters mechanism avail- 
able in the Mizar system. 
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Abstract. Theories play an important role in building mathematical 
knowledge repositories. Organizing knowledge in theories is an obvious 
approach to cope with the growing number of definitions, theorems, and 
proofs. However, they are also a matter of subject on their own: devel- 
oping a new piece of mathematics often relies on extending or combining 
already developed theories in this way reusing definitions as well as the- 
orems. We believe that this aspect of theory development is crucial for 
mathematical knowledge management. 

In this paper we investigate the facilities of the Mizar system concern- 
ing extending and combining theories based on structure and attribute 
definitions. As an example we consider the formation of rough concept 
analysis out of formal concept analysis and rough sets. 



1 Introduction 

The design and the construction of mathematical knowledge repositories is in 
the core of mathematical knowledge management. Computer-supported process- 
ing of mathematics such as knowledge retrieval, distribution over the Internet, or 
development of lecture material is highly driven by the way mathematical knowl- 
edge is represented and maintained. And last, but not least, the acceptance of 
mathematical knowledge management systems by mathematicians themselves 
also depends in essence on how the knowledge in such systems is represented 
and developed. 

Mathematicians build up mathematical theories. However, developing a new 
theory does not (always) mean defining and proving all from scratch: each new 
mathematical theory uses, refines, combines, or extends previous ones. Defini- 
tions and theorems of the constituents are then used without any major refer- 
ence. So for example field theory is a refinement of group theory, field theory 
itself is used in the theory of vector spaces, topology and group theory are com- 
bined in the theory of topological groups, and so on. Thus almost every theory 
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relies on a number of (more) elementary theories. This phenomenon also occurs 
in more computer science related areas, see e.g. [9] where the verification of a 
probabilistic primality test algorithm required proving quite a number of group 
and number theoretical theorems. 

This rather dynamical aspect of theories should be explicitly addressed in 
mathematical knowledge management systems. Developing a theory for a knowl- 
edge repository does not only contribute by introducing new notions, proving 
some new theorems or applying new proof methods. In principle, each theory 
also serves as a starting point for further development in the sense that its no- 
tions, theorems, and proofs are used to construct other theories. We believe that 
mathematical knowledge repositories must take this into account by providing 
language features that enable and support theory development. Furthermore, 
these should reflect the way theories are dealt within everyday mathematical 
life. 

In this paper we focus on theory development in the Mizar system (see the 
website [13] of the project or [19] for details). We formalized the beginnings of 
the theory of rough concept analysis using different approaches - the original 
one as in [11] and its modifications [21]. Rough concept analysis is a synthesis 
of rough sets and formal concept analysis. Rough sets [17] approximate objects 
with respect to an indiscernibility relation. Formal concept analysis [23] is an 
attribute-based approach for representation and analysis of data. The combina- 
tion of both thus establishes a theory for representing and analyzing uncertain 
data. 

Both rough sets and formal concept analysis have already been formalized 
by the authors in Mizar [8,22], however without any intent to use them in other 
theories or even to combine them. Hence, rough sets and formal concept analysis 
provide a good example to investigate the possibilities of Mizar to glue together 
two independently developed theories. 

The plan of the paper is as follows. In the next section we briefly introduce 
rough sets and formal concept analysis and review their Mizar formalization as 
done in [8] and [22]. Section 3 describes the combination of these two theories 
into rough concept analysis. Mizar language features to do so are presented. In 
the last two sections we discuss the Mizar approach for combination of theories 
and compare it to other approaches in the literature. Conclusions for the design 
of mathematical knowledge repositories are drawn. 



2 Rough Sets and Formal Concept Analysis 

In this section we briefly present background for the input theories. Both were 
developed independently, also in Mizar both were formalized in such a way. We 
will focus here on rough sets because of their high level of reusability in many 
different ways. It is well known that in classical set theory in order to define 
a subset X oi a, given universe U we have to specify its membership function 
■ U — > {0, 1}. While for classical sets and multisets these functions are 
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discrete- valued, in the theory of fuzzy and rough sets they are extended to a 
continuous case. 

2.1 Approximation Spaces 

Computers play a special role in the development of the theory of rough sets 
(RST for short). Even if the notion has strong mathematical flavour (although 
its founder, Zdzislaw Pawlak is a computer scientist), it has been used from the 
beginning to approximate knowledge discovery and data mining process. Such 
an approach, called KDD-approach (for Knowledge Discovery in Databases) re- 
sulted in many practical applications, i.e. Rosetta or RSES, just to name the 
most important ones. We believe that KDD is also an important issue for the 
Mathematical Knowledge Management community. 

Nobody however ~ as far as we know - used KDD tools for discovering the 
knowledge about rough sets themselves. One of the reasons probably is the lack 
of a proper, sufficiently big, computer-managed repository of RST knowledge. 
We tried to start with one of them [8], and the results are rather promising, at 
least in the opinion of the authors and the RS community. 

RST is also an interesting subject for machine-oriented formalization for some 
other reasons. Since the introductory paper [17] back in 1982 numerous general- 
izations and improvements of the basic notions have been proposed. The com- 
munity is rather young and fast-growing (the measure of acceptance ratio for 
presented long papers to the RSCTC 2004 Conference in Uppsala, Sweden was 
under 20%, there is also a subseries of LNCS, Springer, Advances in Rough Sets, 
devoted to the topic). On the one hand, machine-formalization of the results in 
such a discipline could be a challenge in itself for many reasons (the results cor- 
respond to different disciplines in mathematics and in computer science and offer 
many possible generalizations which could be discovered automatically etc.). On 
the other hand, one could reach a research frontier here relatively fast. 

The theory of rough sets is a background for a methodology concerned with 
the analysis and modelling of classification and decision problems involving im- 
precise, vague, uncertain or incomplete information. As a result, it distinguishes 
classes of objects rather than the individuals and reflects in a formal way the 
very basic intuition that concept forming is finding out the similarities and the 
differences among objects. There are two simple models for RST in the litera- 
ture. One of them is to have two sets of objects and attributes resp. forming an 
information system. They determine an external similarity relation clustering 
some objects together w.r.t. their attributes (properties). Another formal model 
is an approximation space, the backbone for a whole RST, which is a non-empty 
finite universe U and the indiscernibility relation R given on U. 

Because the latter approach is more often used and methodologically simpler, 
we have chosen it. One of the key issues was also the possibility of further reusing. 
The concept of an information system can be also formalized as the descendant of 
the approximation space in a natural way. At the first sight, the underlying Mizar 
structure is RelStr, which has two fields: the carrier and the InternalRel, 
that is a binary relation of the carrier. The theory of relational structures has 
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been developed and improved mainly during formalization of the Compendium 
of Continuous Lattices (which is described in [1] in detail). While in this context 
RelStr was used with attributes reflexive transitive and antisymmetric 
to establish posets, we decided to reuse it in our own way. First, we defined 
two new attributes: with_equivalence and with_tolerance which state that 
the InternalRel of the underlying RelStr is an equivalence resp. a tolerance 
relation (where a tolerance relation is a total reflexive symmetric relation, see 
[18]). With such defined notions, the basic definitions are as follows: 

definition 

mode Approximation_Space is with_equivalence non empty RelStr; 

mode Tolerance_Space is with_tolerance non empty RelStr; 
end; 

Formalized theories can be treated as objects (axioms, definitions, theorems) 
clustered by certain relations based on information flow. The more atomic the 
notions are, the more is their usefulness. Driven by this idea we tried to drop 
selected properties of the equivalence relations. Our first choice was transitivity 
- therefore the use of tolerance spaces - as it seemed to be less substantial than 
the other two. The generalization work went rather smoothly. As we discovered 
soon, similar investigations, but without any machine-motivations, were done by 
Jarvinen [10]. 

What is rather interesting, one of the referees among the RST community 
complained, that the presentation in [8] is lacking its focus between approxima- 
tion and tolerance spaces. Because every approximation space is in particular a 
tolerance space and this is obvious also for the Mizar type checker, all theorems 
true in more general situations need not (from the viewpoint of the Library Com- 
mittee of the Association of Mizar Users - even must not) be repeated. Some 
theorems holding for tolerances however are simply untrue for equivalences, so 
the apparent lack of focus. For many mathematicians, the uniformity and clarity 
of the approach is still more important than its generality. 



2.2 Rough Sets 

As it sometimes happens among other theories (compare e.g. the construction 
of fuzzy sets), paradoxically the notion of a rough set is not the central point of 
RST as a whole. Rough sets are in fact classes of abstraction w.r.t. rough equality 
of sets and their formal treatment varies. Some authors (as Pawlak for instance) 
define a rough set as an underlying class of abstraction (as noted above), but 
many authors claim for simplicity that a rough set is an ordered pair containing 
the lower and the upper limit of fluctuation of the argument X. 

definition let A be Approximation_Space ; 
let X be Subset of A; 

mode RoughSet of X means :: ROUGHS_l:def 8 
it = [LAp X, UAp X] ; 



end; 
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These two approaches are not equivalent, and we decided to define a rough set 
also in the latter sense. What should be mentioned here, there are so-called modes 
in the Mizar language which correspond with the notion of a type. To properly 
define a mode, one should only prove its existence. As it can be easily observed, 
because the above definiens determines a unique object for every subset X of a 
fixed approximation space A, this can be reformulated as a functor definition in 
the Mizar language. 

If both approximations coincide, the notion collapses and the resulting set 
is exact, i.e. a set in the classical sense. Unfortunately, in the above mentioned 
approach, this is not the case. In [8] we did not use this notion in fact, but we 
have chosen some other solution which describes rough sets more effectively. 

Regardless what approach we are claiming, the key notion of RST is the 
notion of an approximation. A lower approximation of a set X consists of objects 
which are surely (w.r.t. indiscernibility relation of A) in X. Similarly, the upper 
one extends the lower for the objects which are possibly in X (see [8] for detailed 
explanations). 

definition let A be Tolerance_Space ; 

let X be Subset of A; 

func LAp X -> Subset of A equals :: ROUGHS_l:def 4 

{ X where x is Element of A : Class (the InternalRel of A, x) c= X }; 

func UAp X -> Subset of A equals :: ROUGHS_l:def 5 

fx where x is Element of A : Class (the InternalRel of A, x) meets X}; 

end; 

One of the most powerful Mizar linguistic constructions are adjectives (which 
are constructed by attributes). As we found Mizar modes not to be very useful 
within RST after we defined tolerance approximation spaces, we introduced the 
attribute rough in the following way to describe sets X with non-empty approx- 
imation boundary BndAp X (the set-theoretical difference of the upper and the 
lower approximations of a given set X). 

definition let A be Tolerance_Space ; 

let X be Subset of A; 

attr X is rough means :: ROUGHS_l:def 7 
BndAp X <> O; 

end; 

If both the upper and lower approximation of a set X coincide, BndAp X 
equals 0 and AT is a set in the usual sense. In Mizar script, we introduced an 
adjective exact as an antonym to the above to denote crisp sets. The apparatus 
of adjectives has proved its value especially when merging theories together. 

2.3 Formal Concept Analysis 

Formal context analysis (FCA for short) has been introduced by Wille [23] as 
a formal tool for the representation and analysis of data. The main idea is to 
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consider not only data objects, but to take into account properties (attributes) 
of the objects also. This leads to the notion of a concept which is a pair of a 
set of objects and a set of properties. In a concept all objects possess all the 
properties of the concept and vice versa. Thus the building blocks in FCA are 
given by both objects and their properties following the idea that we distinguish 
sets of objects by a common set of properties. 

In the framework of FCA the set of all concepts (for given sets of objects and 
properties) constitute a complete lattice. Thus based on the lattice structure the 
given data - that is its concepts and concept hierarchies - can be computed, 
visualized, and analyzed. In the area of software engineering FCA has been suc- 
cessfully used to build intelligent search tools as well as to analyze and reorganize 
the structure of software modules and software libraries. 

In the literature a number of extensions of the original approach can be found. 
So, for example, multi-valued concept analysis where the value of features is not 
restricted to two values (true and false). Also more involved models have been 
proposed taking into account additional aspects of knowledge representation 
such as different sources of data or the inclusion of rule-based knowledge in the 
form of ontologies. 

Being basically an application of lattice theory FCA is a well-suited topic 
for machine-oriented formalization. On the one hand it allows to investigate the 
possibilities of reusing an already formalized lattice theory. On the other hand 
it can be the starting point for the formalization of the extensions mentioned 
above. In the following we briefly present the Mizar formalization of the basic 
FCA notions necessary for the next section. 

The starting point is a formal context giving the objects and attributes of 
concern. Formally such a context consists of two sets of objects O and attributes 
A, respectively. Objects and attributes are connected by an incidence relation 
I C O X A. The intension is that object o G O has property a G A if and only 
if (o, a) G I. In Mizar [22] this has been modelled by the following structure 
definitions. 

definition 

struct 2-sorted (# Objects, Attributes -> set #) ; 

end; 

definition 

struct (2-sorted) ContextStr 
(# Objects, Attributes -> set. 

Information -> Relation of the Objects, the Attributes #) ; 

end; 

Now a formal context is a non-empty ContextStr. To define formal concepts 
in a given formal context C two derivation operators DbjectDerivation(C) and 
AttributeDerivation(C) are used. For a set O of objects {A of attributes) the 
derived set consists of all attributes a (objects o) such that (o, a) G I for all 
o G O (for all a G A). The Mizar definition of these operators is straightforward 
and omitted here. 
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A formal concept FC is a pair {O, A) where O and A respect the derivation 
operators: the derivation of O contains exactly the attributes of A, and vice 
versa. O is called the extent of FC, A the intent of FC. In Mizar this gives 
rise to a structure introducing the extent and the intent and an attribute 
concept-like. 

definition let C be 2-sorted; 

struct ConceptStr over C 

(# Extent -> Subset of the Objects of C, 

Intent -> Subset of the Attributes of C #) ; 

end; 

definition let C be FormalContext ; 

let CP be ConceptStr over C; 

attr CP is concept-like means :: CONLAT_l:def 13 

(ObjectDerivation(C) ) . (the Extent of CP) = the Intent of CP & 
(AttributeDerivation(C) ) . (the Intent of CP) = the Extent of CP; 

end; 

definition let C be FormalContext; 

mode FormalConcept of C is concept-like non empty ConceptStr over C; 

end; 

Formal concepts over a given formal context can be easily ordered: a formal 
concept FCi is more specialized (and less general) than a formal concept FC 2 
iff the extent of FC\ is included in the extent of FC 2 (or equivalently iff the 
intent of FC 2 is included in the intent of FCi). With respect to this order 
the set of all concepts over a given formal context C forms a complete lattice, 
the concept lattice of C. 

theorem 

for C being FormalContext holds ConceptLattice (C) is complete Lattice; 

This theorem, among others, has been proven in [22]. The formalization of 
FCA in Mizar went rather smoothly, the main reason being that lattice theory 
has already been well developed. Given objects, attributes and an incidence 
relation between them, this data can now be analyzed by inspecting the structure 
of the (concept) lattice; see [23,7] for more details and techniques of formal 
concept analysis. 



3 Rough Concept Analysis 

In this section we present issues concerning the merging of concrete theories in 
the Mizar system. Since we want to keep this presentation possibly self-contained 
and we assume basic knowledge of Mizar syntax (which is very close to the 
language used by mathematicians), we will illustrate them by living examples 
from Rough Concept Analysis and skipping most technical details. For details 
of the Mizar type system, see [2]. 
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Below we enumerate ten features that proved their usability in merging the 
theories of RST and FCA. Though they are Mizar specific we claim that any 
mathematical knowledge should support the general principles of these features 
in one or another form in order to make theory development more feasible. We 
like to mention that in the course of FCA formalization the formal apparatus 
yet existing in the Mizar Mathematical Library also had to be improved and 
cleaned up. 

Data Structure. A basic structure for the merged theory should inherit fields 
from its ancestors, which would be hard to implement if structures were im- 
plemented as ordered tuples (multiple copies of the same selector, inadequate 
ordering of fields in the result). The more feasible realization is by partial 
functions rather, and that is the way Mizar structures work, 
definition 

struct (ContextStr, RelStr) RoughContextStr 
(# carrier, carrier2 -> set. 

Information -> Relation of the carrier, the carrier2, 
InternalRel -> Relation of the carrier #) ; 

end; 

The maximal number of fields in a single structure in the Mizar library is 
ten (as of a Cartesian category). The choice of having a long structure with 
many specialized inherited fields is what actually depends on the author. On 
the one hand an ordering can be defined in a natural way as an external pred- 
icate, e.g. on concepts. On the other hand, using the internal field of a struc- 
ture one can benefit from the notions and theorems about relational struc- 
tures. It is hard to formulate quantitative criteria in this subject, but it seems 
that six is a good upper approximation for a number of structure fields. 

Homogeneous Structure Hierarchy. In Mizar the same names of fields are 
necessary to merge structures (the problems with multiple carriers), some 
automatizing could be made, though. The same names of operations or at- 
tributes will result in serious troubles if one has them together with different 
meanings assumed originally. As it can be observed from the previously 
cited example, the first two selectors have the names carrier and carrier2 
which is incompatible with the names of ascendant structures (Objects and 
Attributes occurring in ContexStr vs. carrier in RelStr). Since there 
are no synonyms for selectors in Mizar, a revision for ContextStr had to be 
made. This policy however is highly unlikely and Mizar developers should 
consider a language extension. 

Apart from its visualization (see “Net of structures in MML” (MML 
stands for Mizar Mathematical Library) section at [13]), we gather basic 
data about structures in Table 1. As it can be concluded, the clustering of 
structures is good. Every fourth structure inherits its fields from at least 
two others, so the background for theory merging is comparatively well pre- 
pared. As a future work for the Library Committee, the number of initial 
(i.e. without parents) structures should be decreased. 
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Table 1. Statistical data about structures in MML 



Description 


Quantity 


% of total 


descendants of 1-sorted 


72 


79 


prefixed by 1-sorted 


23 


25 


initial 


15 


16 


standalone 


12 


13 


multiprefixed 


22 


24 


structures total 


91 


100 


articles using structures 


533 


64 


articles total 


834 


100 



Forgetful Functors. The user would have a chance to use an original part of 
merged object with a type of its parent, i.e. the back-translation should be 
provided where possible. It is provided in Mizar by the construction 

the Structure- symbol of Variable 

In this manner, if a RoughContextStr X is given, the RelStr of X will 
result in the rough part of the structure X. 

Strict Objects. Sometimes it is useful to deal only with the objects with the 
type of source theories even if we work within a target theory. The term 

strict Structure- Symbol 

yields an object without any additional fields than those in the input struc- 
ture, e.g. strict ContextStr denotes the structure of a formal context with- 
out mentioning its roughness aspect. 

Inheritance of Properties. It is natural to have notions formulated as general 
as possible, especially in a large repository, when unnecessary assumptions 
are inherited in some sense. The care is advised here, because if the definition 
of the lower approximation were introduced as follows: 

definition let A be strict Tolerance_Space ; 
let X be Subset of A; 
func LAp X -> Subset of A equals 

{x where x is Element of A : Class (the InternalRel of A,x) c= X}; 
end; 

i.e. with tolerance space without any additional fields as a locus, this notion 
might not be used within RCA. There is software available in the Mizar 
system detecting some unnecessary assumptions, but not those searching for 
a more general type which may be used. Of course, the above functor has 
been defined in [8] without adjective strict. 

Free Extensions. As it often happens, an extension of the theory to another 
need not be unique. There are at least three different methods of adding 
roughness to formal concepts [11,21]. The question which approach to choose 
depends on the author. The notion of a free structure in a class of descendant 
type conservative w.r.t. the original object is very useful. 
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definition let C be ContextStr; 

mode RoughExtension of C -> RoughContextStr means 
the ContextStr of it = the ContextStr of C; 

end; 

Now, if C is a given context, we can introduce roughness in many different 
ways by adjectives. 

Interferences. Up to now, we described only mechanisms of independent inher- 
itance of notions. Within the merged theory it is necessary to define connec- 
tions between its source ingredients. Here the attributes describing mutual 
interferences between selectors from originally disjoint theories proved their 
enormous value. They may determine the set of properties of a free extension. 

definition let C be RoughFormalContext ; 
attr C is naturally_ordered means 
for x, y being Element of C holds 
[x,y] in the InternalRel of C iff 

(ObjectDerivation C).fx} = (DbjectDerivation C).{y}-; 

end; 

Since the relation from the definiens above is an equivalence relation on the 
objects of C and hence determines a partition of the set of objects of C into 
the so-called elementary sets, it is a constructor of an approximation space 
induced by given formal context. 

Inherited Theorems and Clusters. Theory merging makes no sense, if prov- 
ing the same theorem would be necessary within both source and target 
theory. Since a new Mizar type RoughFormalContext is defined analogously 
to the notion of FormalContext, as non quasi-empty RoughContextStr 
(compare Subsection 2.3), the following Fundamental Theorem of RCA is 
justified only by the Fundamental Theorem of FCA. Even more, clusters 
providing automatic acceptance of the original theorems do it analogously 
within target theory. That is also a workplace for clusters rough and exact 
mentioned in Subsection 2.2. 

for C being RoughFormalContext holds 

ConceptLattice (C) is complete Lattice by C0NLAT_1:48; 

Uniform Object Naming. We should work out a comfortable and uniform 
naming system for attributes. E.g. it is a rule that the structure prefixed by 
1-sorted is named non empty provided its carrier is non-empty. But how it 
should be named to describe the ‘second carrier’ to be non-empty? This con- 
cerns multi-sorted structures in general. We want to find a reasonable com- 
promise between technical naming and that close to a natural language, but 
the reasonable length of a name is also an important criterion. So between 
non empty2 and withjnon_empty_carrier2 we decided to use quasi-empty. 

Synonyms for Objects. Although uniform name spaces improve especially 
the searching process, sometimes having the same notationfor different no- 
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tions is a serious drawback. Lattice theory can bring more appropriate ex- 
amples: on the one hand we have binary suprema and infima operations in 
a properly defined lattice, on the other hand those in a relational structure 
induced by the ordering. If we merge both, the problems with identification 
occur, so it is reasonable to introduce a new notational synonym for one of 
them, e.g. 



notation let R be RelStr, 

X, y be Element of R; 
synonym x "l_l" y for x "\/" y; 
end; 

(where "\/" stands for an original binary supremum in lattices). 



4 Mathematical Knowledge Repositories 

Mathematical knowledge management aims at providing mathematics with the 
help of computers. One major point in doing so is to build repositories holding 
the knowledge. We believe that mathematical knowledge repositories should be 
more than simple databases, that is the knowledge included should be verified 
by a prover or checker in order to avoid the inclusion of untrue knowledge. 
However, even then revisions may become necessary. We have seen this in the 
course of formalizing rough concept analysis, where renaming of the selectors of 
structure ContextStr was necessary in order to fully benefit from the inheritance 
mechanisms in Mizar. Thus the organization and maintenance of mathematical 
knowledge repositories is, and will stay, an ongoing process. In the following 
we report on the latest developments concerning MML, discuss the evolution of 
mathematical repositories and briefly review other approaches to theory building 
from the literature. 

4.1 Mizar Mathematical Library 

The Mizar Mathematical Library [13] is the (still evolving) result of a long term 
project that aims at developing both a comprehensive library of mathematical 
knowledge and a formal language - also called Mizar - for doing so. So far 
MML just collects articles written in the Mizar language. At the time of writing 
there are 834 articles with 36847 theorems/lemmas and 7093 definitions included, 
written by more than 150 authors. 

Recently the development of the Encyclopedia of Mathematics in Mizar 
(EMM for short) has been started. Here definitions and theorems of MML are ex- 
tracted semi-automatically into new articles with monographical character. This 
obviously becomes necessary having a larger number of authors who introduce 
definitions and theorems whenever these are convenient for the author’s goals 
- and not when it seems reasonable to introduce them in order to get a well- 
developed repository. So far there are five EMM articles (XB00LE_0, XB00LE_1 , 
XREAL_0, XCMPLX_0, and XCMPLX_1) including basic facts on boolean operators, 
real and complex numbers. Thus, in some sense, theories are built in EMM by 
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collecting knowledge (belonging to the same topic) spread over the whole library. 
In parallel, work on the environment directive requirements continues which 
strengthens the Mizar checker in the following sense: requirement files contain 
statements that become obvious for the Mizar checker if the file is included in 
the environment. So far properties of real and complex numbers as well as of 
boolean operators and of subsets has been addressed. 

In the course of developing EMM and the requirements directive we propose 
to also include theories based on structures and attributes such as for example 
groups, fields, or even RST or FCA. As a consequence these theories could be 
easier imported into new articles improving both the organization and reusing 
facilities of MML. 

4.2 Evolution of a Repository 

Though we cope mainly with the question of computer-supported mathematical 
theory development in this paper, machine-managed knowledge retrieval from 
a repository of mathematical facts is also an important issue, especially if one 
considers KDD-based methods usage. 

The larger the database is, the easier linkages and connections can be stud- 
ied. Even if MML is known as the largest library of formalized mathematics, it 
has a number of disadvantages. C-CoRN [4] , the Constructive Coq Repository at 
Nijmegen, uses experience gathered when building MML. The number of people 
involved in this project is rather small (about 15 in total) as their library is 
centralized as a rule. C-CoRN grew out as a side-effect of the Fundamental The- 
orem of Algebra project. It is not an objection in any sense, but some obstacles 
might be anticipated in this way and carefully be discussed. The data structure 
may also profit from the uniform manner of its design. Searching for analogies, 
e.g. between fuzzy and rough sets, can be more successful if both are coded in 
similar manner or if they can be lifted to a common formal platform. 

In this paper we address only issues of what Trybulec and Rudnicki [19] 
classify as abstract mathematics. In classical mathematics theories are hardly 
merged, but rather inherited. It is one of Trybulec’s recent suggestions to cut 
MML into classical (not using the notion of a structure) and abstract mathe- 
matics to study interconnections between theories more carefully. There is also 
the opinion, that this will make the library more coherent, where by a ‘coher- 
ence’ we mean, similarly to [4], that results about a specific theory should be 
grouped together and theories extending others should be built on the top of 
them. 

What we are going to do with MML is to make it better organized but we 
have to watch for authors’ rights as well. They sign a copyright form when 
submitting to MML and the Library Committee of the Association of Mizar 
Users can revise their work. However, the copyright issues should be discussed 
by the MKM community since the importance of electronical repositories is 
growing remarkably. 

It is hard to imagine a living system without any changes anyway. If the 
interfaces evolve, repositories can follow their development and vice versa, by 
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exploring knowledge stored in libraries, new techniques can be worked out. In 
MML CVS service which is publicly available (by a usual Concurrent Version 
System engine with web-browsing facility) official versions of MML are archived 
to document revision stages. Since its initial version in May 2002, nearly 150 
versions were archived (as of June 2004). It shows rather dynamic growth of 
the repository, especially if one takes into account that not all intermediate 
stages of the library were stored (some of the versions of the system consisted 
only of the new compilation of the executables etc.). The policy of the Library 
Committee of the Association of Mizar Users is that MML is archived in CVS as 
a whole because of the many interdependencies. Just for the record how tight this 
structure is, let us note here that there are nearly 500 thousand cross-citations 
(for definitions and theorems, internal references are not counted) between Mizar 
articles. 

4.3 Other Repositories 

The IMPS system [6] provides theory development in forms of the little theories 
approach [5]. Here theories are developed with respect to a particular set of 
axioms which can be compared to using a set of attributes in Mizar. To use a 
theorem in another context a theory interpretation is constructed. This usually 
includes a number of obligations ensuring basically that axioms of the old theory 
are mapped to theorems in the new one. Combining theories therefore can be 
done by establishing the axioms of the new theory and importing theorems via 
theory interpretations. 

A similar approach can be observed in PVS [16], via the mapping mechanism 
it is easy to specify a general theory and have it stand for a number of instances 
(the latter correspond to an aggregate in Mizar) . Theory declarations allow theo- 
ries to be encapsulated and instantiated copies of the implicitly imported theory 
are generated. In Isabelle/Isar [15] there are mechanisms of merging both the- 
ories and locales. The latter modules correspond to a context rather which is a 
narrower notion than we dealt in this paper. 

In Theorema [3] theories can be constructed by using a special language 
construct. This allows to explicitly state which definitions, lemmas, and theorems 
are part of the theory. Thus every user can construct his own theories. These 
theories are then used as attachments to proof attempts in this way reusing 
the knowledge stored in a theory. A theory may include theories again so that 
hierarchies of theories can be built. 

Tecton [14,12] is a specification language developed mainly for the descrip- 
tion of requirements for generic algorithms. It does include language constructs 
to formulate lemmas and theorems, but unfortunately no means to prove these 
correct. However, theories can be combined by gluing together already existing 
theories using the so-called refinement. This basically means that the axioms of 
the old theories are imported into the new one, in this way ensuring that theo- 
rems of used theories still hold. Furthermore, in doing so carriers and operators 
can be renamed which makes the language more flexible and user-friendly. 
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5 Conclusion 

The aim of mathematical knowledge repositories is twofold: On the one hand 
a repository has to provide language and proof constructs to represent mathe- 
matical objects and proofs in a convenient way. On the other hand, even more 
important for mathematical knowledge management, the knowledge stored in a 
repository must be kept manageable in the sense that both retrieving and ex- 
tending it is supported. Building, refining, and extending theories is an obvious 
approach to organize knowledge in mathematical repositories and therefore cru- 
cial for the development of mathematical knowledge repositories; in particular 
the flexibility of theories as known from everyday mathematical life has to be 
addressed. We believe that constructing - and hence refining and extending - 
theories using structures and attributes as presented in this paper is a step into 
this direction. 
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Abstract. In this paper we are interested in the process of formalizing a 
mathematical text written in Common Mathematical Language (CML) 
into type theory using intermediate representations in Weak Type The- 
ory [8] and in type theory with open terms. We demonstrate that this 
method can be reliable not only in the sense that eventually we get for- 
mally verified mathematical texts, but also in the sense that we can have 
a fairly high confidence that we have produced a ‘faithful’ formalization 
(i.e. that the formal text is as close as possible to the intentions expressed 
in the informal text). 

A computer program that assists a human along the formalization 
path should create enough “added value” to be useful in practice. We 
also discnss some problems that such an implementation needs to solve 
and possible solntions for them. 



1 Introduction 

The de Bruijn criterion for reliability of proof-checking systems states that a 
proof created with arbitrarily complex techniques can be reliable as long as the 
final proof object can be checked by a small (i.e. manually verifiable) program. 
Obviously, this criterion concerns the proof construction after the problem has 
been translated into the language of a formal system. However, there is a stage 
prior to that: the transition from informal to formal and when it comes to reli- 
ability, both stages are important. 

Hence there is also the question of how to create reliable formal translations 
of the informal mathematical problems and proofs. The process of formalizing 
a piece of informal mathematical text is about making explicit the intentions of 
the author of the text. As such, we can never be completely sure what the author 
of the text had intended to say and more importantly, we cannot be sure whether 
the piece of formal text faithfully reflects these intentions. Therefore, almost by 
definition the formalization is and probably always will remain a process that 
involves a human decision. 

One way to ensure a level of reliability is to use a very weak formal system in 
the first translation step. The key observation is that by making an initial formal 
version as close as possible to the informal version, the detection of formalization 
errors will be much more likely. In [9, 8] a system called Weak Type Theory 



A. Asperti et al. (Eds.): MKM 2004, LNCS 3119, pp. 145—159, 2004. 
© Springer- Verlag Berlin Heidelberg 2004 




146 G. Jojgov and R. Nederpelt 



(WTT) is proposed that tries to conform to this idea by introducing a language 
to write formal mathematical texts in which the concern of the reliability of the 
translation is separated from (and has precedence over) the concern about the 
logical content of the text. The typing system of WTT is not so much focused 
on the formulas-as-types paradigm as on the goal of capturing the syntactic and 
linguistic structures of informal texts. For example, in WTT we have weak types 
for nouns, adjectives, sets, etc. 

As regards the second stage of the formalization, there is also more to say 
about reliability than only the compliance with the de Bruijn criterion: in order 
to keep close to the intentions of the mathematical author, it is probably advis- 
able to do proof construction more ‘human-friendly’, in the style of the average 
mathematician. The problem is evident if one looks at the user group of interac- 
tive theorem provers which in its majority consists of highly trained specialists. 
Their expert knowledge is not only needed to create formal texts with the tools, 
but also to translate informally stated problems into the language of the partic- 
ular tool. In our opinion, a careful, more human-oriented tuning of both stages 
of proof construction, can make interactive theorem provers more widely used 
and more importantly, it can increase the reliability of the overall formalization. 

In this paper we study to which degree WTT can convincingly perform the 
role of a system for initial formalization and how a WTT text can then be 
evolved into a fully formalized text in a full-featured type theory. To do that 
we will need to translate WTT texts into a type theory with incomplete proofs 
and terms. Such proofs and terms have missing parts that need to be proven or 
constructed and this is a task that is well understood and supported in modern 
interactive theorem provers [2]. In other words, this paper is an initial study of 
the feasibility of using WTT as a ‘front end’ for theorem provers and it does not 
have the purpose of proposing yet another prover. 

The main line of events is hence as follows: we have an informal text of which 
we want to create a fully formalized version. The first step is to translate this 
text into WTT. As the constraints imposed are weak, the distance of the WTT 
text from the original can be kept minimal to reduce the chance for formalization 
errors. Then we will translate this WTT text into a version of our target type 
theory with incomplete proofs and terms and global definitions. The missing 
parts in these proofs and terms are explicit representations of the details that 
are left implicit in the informal version. Once we have the version with incomplete 
terms and proofs we are in the conventional domain of theorem provers. 

The benefits of such an approach are manyfold. First, we have increased the 
reliability of the initial formulation of the informal text into a formal system. 
Second, the translation from the weak WTT to the strongly typed target type 
theory exposes many opportunities for automation and hence for creating ‘added 
value’ for the user. The third benefit, already discussed in previous work (see 
[7]) is that the resulting type theory text reflects the structure of the informal 
document we started with. This could allow us to trace back to the original 
informal text, any errors found during the later stages of formalization. 
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2 The Formalization Path 

In this section we discuss in more detail the three translations on the path 
from the Common Mathematical Language (CML) through Weak Type Theory 
(WTT) and Type Theory with open proofs (OTT) to the final goal of a complete 
formalization in Type Theory (TT). 

2.1 Step 1: Prom Informal Text to Weak Type Theory 

In this section we illustrate the ideas explained above by showing how a piece of 
informal mathematics could be translated using our approach. Consider the text 



A function from natural to naturals is increasing if the value of the 
function at a given point is strictly less than the value at the next point. 
We say that a function / is unbounded if for every natural number there is 
an argument of the function for which the function takes a value greater 
than that natural number. 

Theorem 1. Every increasing function is unbounded. 

Proof. Let / be an increasing function. First, using induction we will 
prove that 'ix € N{f{x) > x): 

Base /(O) is a natural number and hence /(O) > 0. 

Ind. Step If f{k) > k we have that f{k + 1) > f{k) because / is 
increasing. Hence f{k + 1) > k and this means that f(k + 1) > fe + 1. 

Now, choose an arbitrary natural number n. According to the above we 
have /(n + l)>n+l and hence /(n + 1) > n. This means that there 
is an argument of the function (namely n + 1) for which it takes a value 
greater than n. □ 



Fig. 1. A piece of mathematical text as written in the Common Mathematical Lan- 
guage (CML) 



shown in Fig. 1. Looking at the structure of the text we notice that it contains 
two definitions (of the notions increasing and unbounded) and a theorem with 
its proof. This general structure is preserved in the translation of the text into 
WTT which is shown in Fig. 2. 

Formally, the WTT text is called a hook (we follow de Bruijn [4] who used 
this format in his pioneering Automath project). Books are lists of lines and 
a line is either a statement or a definition under a context. We represent the 
context by (nested) flags, with flag staffs denoting their scope. For example, the 
statement line /(O) > 0 in Fig. 2 has as context / : Increasing Function and the 
line f{k -F 1) > fc -F 1 has as context / : Increasing Function, k:N,f{k)>k. 

The syntax of the subset of WTT that we consider here is given below. It 
contains all essential components of WTT with exception of some extra binders 
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Function := {N N) J, 

Increasing := ^dj/;FunctionV„:jv(/(n + 1) > f{n)) 
Unbounded := ^dj/;FunctionV„:iv3m:iv/(m) > n 
f : Increasing Function 

/(O) > 0 

fc : N\ 

|/(fc) > fc 

/(fc + 1) >/(fc) > k 
/(fc + 1) > fc + 1 
Vfc;jv/(fc) > k 
n : A^l 

f{n + 1) > n + 1 
f{n + 1) > n 
3rn:iv/(m) > n 

/ is Unbounded 

V/;|ncreasing Function/ is Unbounded 



Fig. 2. Translation of the text from Fig. 1 into Weak Type Theory (WTT) 



and constants that we have chosen not to include in order to keep the exposition 
clear. 

term T ::= x \ c{V) \ Xz'T 

adjective A ::= Adjz(Sp) 

noun Af ::= c{V) \ N ounz{Sp) \ Abstz{T /Af /Ss) \ AAf \ Ss i 

set Sg ::= x \ c{V) \ Setz{Sp) \ Af t 

statement Sp ::= x \ c{V) | — > 5p | ^ z{Sp) \ 3^(5p) | T is .4 

argument V ::= Sg \ Sp \ T 

declaration Z ::= x:SET | x:STAT | x: A/"! x:Sg 
context r ::= 0 I T, Z I F,Sp 
definition V ::= c(x) := (T /Sp/Sg/ A/N) 
line I ::= F >D \ F t> Sp 
book B ::= \ B o I 

For a complete description of WTT, including examples, we refer the reader to 
[8] . Here we will only briefly comment on some elements of the syntax used in our 
examples. The main weak types are term, adjective, noun, set and statement. A 
noun is used for indefinite descriptions, like ’a natural number greater than zero’ 
(which is expressed by Nounn-.N{Q < n). Adjectives are used to denote properties 
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and may be applied to nouns {AN above) or to terms (T is A). The operators 
t and I are used to convert a noun to a set and conversely. The binder Set 
is used for set comprehension. Statements are formed from atomic propositions 
(constant instances) and the usual connectives and quantifiers. The notation V 
and X is used to denote (possibly empty) lists of objects of the corresponding 
category. 

Fig. 2 contains the WTT text representing the informal text in Fig. 1. We 
have used some “syntax sugaring” (e.g. infix notation) to make the text more 
readable. Comparing the informal and the WTT text we can see that: 

— the definitions and the statements in the text are clearly identified; 

— the scope of all variables is explicitly specified either by a flag or a binder; 

— no requirements are imposed on the logical validity of the statements. In 
particular, there is no commitment to a specific logical system (classical, 
intuitionistic, etc.); 

— the WTT text is still readable by a mathematician; 

— formalization choices to resolve ambiguities in the original text (which poten- 
tially could introduce formalization errors) have been reduced to a minimum. 



2.2 Step 2: Fhom Weak Type Theory to Type Theory with 
Incomplete Terms 

Once we have translated the CML text to WTT and after making sure that the 
formal version faithfully captures the intended meaning of the informal one, we 
can look further down the formalization path. 

At this point we do have to make a number of choices that may significantly 
influence the final result. For example, we need to choose the target system 
in which the fully formalized text should be represented. Here we have chosen 
dependent type theory as a target system but, at least in principle, we could 
choose also another system. We use dependent types among many other reasons 
also because there are versions of it that support incomplete terms which as we 
will see is very useful for our purposes. So, to fix the setting of the paper, in 
the rest of the paper we will assume that the target system is a dependent type 
theory in PTS style [1] which admits global parameterized definitions, constants 
and meta- variables [6]. 

The basic idea is to translate the WTT text into type theory with incomplete 
terms. Incomplete terms are terms with missing parts that are represented by 
meta-variables. We naturally obtain such terms from WTT texts because the 
reasoning steps are not included in WTT and because some implicit information 
in the WTT needs to be made explicit for the sake of the stronger typing. 

To make the intended translation more intuitive, we will introduce flag no- 
tation for the type theory. Here are the main features and the differences with 
the flag notation for WTT: The syntax of the terms is the one of the typing 
system (i.e. typed A-calculus) and the text is again structured in books consist- 
ing of lines under zero or more flags. In contrast to WTT, here all flags contain 
variable declarations and every line has the form 




150 G. Jojgov and R. Nederpelt 



X : A 

c(x) := M : B 



flags in scope 
deflnition line 



where A and B are types and M is either a term or one of the special sym- 
bols open and prim. When M is a term, the line is a deflnition of c(x); when 
M is open, this indicates that the line declares that c{x) is a meta- variable 
standing for an unknown term of type B. When M is prim, this is an indica- 
tion that c(x) is an uninterpreted (axiomatic) constant. The difference between 
a meta-variable and an axiomatic constant is that the meta-variable denotes 
an unknown term that we look for and hence at some point when this term 
becomes known, we have to convert the meta-variable declaration into a ‘real’ 
deflnition. 

After we defined the flag notation for type theory with open terms, we need 
to give the rules for deciding whether a book is strongly well-typed. There are 
two approaches - a direct and an indirect one. The direct one is to give typing 
rules for flagged books. We choose the indirect one which is for each book to 
define a typing judgment in the standard notation and to postulate that a book 
is well-typed if and only if that typing judgment is derivable. This process is 
explained in more detail in Section 4. 

In Fig. 3 we can see the OTT version of the text of Fig. 1 and Fig. 2. We 
notice that here all lines are in the form of definitions and have labels in the 
form of the constant being defined. 

The process of translating a WTT book into OTT is rather involved. In this 
case we see that the adjectives have been translated into predicates and that 
the nouns have become types of sort Set. Declarations involving complex nouns 
like / : Increasing Function are split into a declaration of an object of the type 
to which the noun is mapped (/ : Function) and an assumption that this object 
satisfies the predicate to which the adjective is mapped (/i : Increasing(f)). 

Statements of the form ‘M is A’ where M is a term and A is an adjective are 
translated to the propositions stating that M satisfies the predicate of A. The 
logical connectives and quantifiers are straightforward to map using the usual 
propositions-as-types embedding. 

In WTT a deflnition has the form c(x) := M while here we need c(x) := 
M : A. This requires that we first translate the term M and then use the type 
inference algorithm in the target type theory to And the type A. 

Apart from the technical details, at this stage we are looking for a mechanism 
to translate as big a part as possible of the weakly well-typed WTT derivations 
into OTT. It is clear that there are many for which this is not possible simply 
because there is no possible strong typing for some weakly typed texts. How- 
ever for those that this is possible, it may be difficult to do it automatically 
because of a number of reasons. We discuss some of the problems in Section 3. A 
practical implementation needs to And the right balance between performance 
and completeness since the more we try to expand the set of translatable WTT 
derivations, the more difficult problems we will confront. Where exactly this 
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Function := {N N) : Set 
/ : Function 

lncreasing(/) := y„:N{f{n + 1) > /(n)) : Prop 
Unbounded(/) ■■=Vn:N^m:Nf{m) > n : Prop 
/ : Function 
h : lncreasing(/) 

Li[f, h] ■- open : /(O) > 0 
|fc : A^l 
g : /(fc) > k 

L 2 [f,h,k,g] ■- open : f{k + 1) > f{k) > k 
Lslf, h,k,g] ~ open : f{k + l)>k + l 
Li[f, h] ~ open : \/k:Nf(k) > k 
\n :N\ 

Ls[f, h, n] open : f{n + 1) > n + 1 

1/6 [/, h, n] open : f{n + 1) > n 

Lt[/, h, n] ■— open : 3m-.Nf{rn) > n 
Ls[/, h] := open : Unbounded(/) 

Lg := open : V/;Functionlncreasing(/) — + Unbounded(/) 



Fig. 3. Translation of the WTT text from Fig. 2 into Type Theory with open terms 
in flag notation 

balance lies is difficult to estimate and practical experiments are necessary to 
establish it. 



2.3 Step 3: Ftom Type Theory with Incomplete Terms to Type 
Theory 

This is the last of the three steps in the formalization path that we discuss. 
So far we have a strongly well-typed flagged book in type theory with open 
terms and our goal is to fill in all remaining open places. These open places 
would typically be all proof steps in the proofs; proof obligations when using 
conditional definitions; terms used as witnesses which are implicit in the informal 
text, etc. 

We should point out that the tasks required at this stage are the typical tasks 
performed with an (interactive) theorem prover based on type theory. We have a 
problem which is already formally stated and within the language of the prover 
and our goal is to construct terms of certain types that correspond to the open 
places in the OTT text. 
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Hence, at this point we could decide to use an interactive theorem prover 
to construct the missing parts and this is probably the best choice. Modern 
provers are complex software systems that offer a lot of help to the user in 
form of tactics and decision procedures for quickly making relatively large proof 
steps. We could mention among many others Coq [5], LEGO [10], Mizar [11], 
etc. 

In this paper we would like to show however that the process of term con- 
struction in a theorem prover can be modeled in a natural way using flagged 
books. To illustrate that we take a part of the derivation in Fig. 3 and show how 
the basic steps of proof construction in the prover can be modeled inside the 
OTT. 

Consider the first derivation in Fig. 4. It depicts a part of the OTT text 
from Fig. 3. Ly there stands for the yet unknown proof of the existential state- 
ment 

> n 

To do that, suppose that we have a term exJntro representing the introduc- 
tion rule for the existential quantifier. This means that we have 

ex -intro : UU : Set. TIP: {U — > Prop). nt:U.IIh:{Pt)3xu{Px) 

In other words, when applied to a set U , a predicate P on it, an element t of 
U and a proof of P{t), ex -intro would be a proof of 3x:uP{x). 

The second derivation in Fig. 4 shows an application of ex-intro to unknown 
arguments Ly,Ly,Ly and Ly which of course is a proof of 3^.^iL^{x). However, 
our goal is to solve Ly which should be of type existSm:Nf(jn) > n. Hence 
we see that to use ex-intro to solve Ly we need to solve Ly by N and Ly by 
\m.f{m) > n. 

This leads to the third derivation and now we have to find the witness m 
and a proof that f{m) > n. Recall however that Lq is an unknown proof of 
f{n -I- 1) > n. If we try to use Lq as a last argument of eX-intro, we see that in 
order to get a typable term, Ly has to have the value n -I- 1. This is depicted by 
the final derivation in Fig. 4. 

Continuing in a similar way we can fill in the rest of the open goals in the 
derivation as this is shown on Fig. 5. For brevity we have omitted the types of 
the variables in A-abstractions there. 

3 Some Problems During the Translation of WTT Texts 
into Type Theory 

Usually a typing system used in a theorem prover requires much stronger typing 
than the one required from the weakly well-typed texts. It is hence natural to 
expect that there will be problems when one tries to translate a WTT text to 
such a system. In this section we discuss several of these problems and possible 
solutions for them. 
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/ : Function 
h : lncreasing(/) 
n : A^l 

Le open : f{n + 1 ) > n 
Lr open : 3m;jv/(m) > n 



/ : Function 
h : lncreasing(/) 

\n : N\ 

L\ := open : Set 

L7 := open : L\ Prop 

L7 := open ; L\ 

:= open ; if (L7) 

L? := exAntro{L\,LlLm) : 
L7 := open : > n 



f : Function | 
h : lncreasing(/) 
n : N\ 

L7 ;= open : L\ 

L| ;= open : Lf (if) 

L 7 ;= exJntro{N,Xx.f{x) > n,L^,Lj) : 3m:Nf{m) > n 



f : Function | 
h : lncreasing(/) 
n : Af| 

L 7 := exJntro{N,\x.f{x) > n,n + 1 ,Lq) : 3m:iv/(m,) > n 



Fig. 4. Sequential refinement steps. We have left out the trivial parameter list /, h, n 
after each of the constants (e.g. L 7 should be read as L^[f, h, n]) 

3.1 General Problems 

The path from CML to Type Theory that we explore in this paper has a number 
of advantages in terms of the reliability of the formalization, the fact that it is 
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/ : Function 
h : lncreasing(/) 



In : N\ 

Lsl/, fe, n] := I/4(n+ 1) : /(n + 1) > n + 1 
Le[f,h,n\ ;= leJt{f{n+ l),n, Ls,[f,h,n]) : f{n+ 1) > n 
Lr[f, h, n] ;= exJntro{N, {\m.f{m) > n), n + 1, -Lei/, h, n]) : 3m,:Nf{m) > n 
-Lg[/, /i] := \hn.exJntro{N, {\m.f{m) > n),n+ 1, Le[/, L, n]) : Unbounded!/) 

Lg := \fhn.exAntro{N, {Xm.f{m) > n), n + 1, -Le[/, h,n]) : 

: V/;Functionlncreasing(/) — > Unbounded)/) 

Fig. 5. A possible completion of bottom part of the OTT text. The term leJt denotes 
a proof of the lemma 'in'ikin > k -\- 1) ^ (n > k) 

quite natural (and hence easy to use), etc. but we cannot avoid the problems 
that any formalization needs to solve. 

Such problems are in the first place to choose the target system and how 
logic or other aspects of the original text will be interpreted in that system. For 
example, in Type Theory one distinguishes between deep and shallow embed- 
ding of a logical system. An embedding is deep when the connectives and the 
quantifiers are interpreted as types in the system (for example, A ^ B becomes 
Up: A.B or Va; : U.A{x) becomes Ux : U.A{x)). The shallow embedding is used 
in the so-called logical frameworks to define different logics by introducing con- 
stants representing the connectives and quantifiers. Both approaches have their 
pros and cons and one should make a choice based on other factors like in what 
context the formalization is going to be used. 

3.2 Conditional Definitions 

In Fig. 6 we see a definition of a predicate (divides(m, n)) under a certain con- 
dition (m yf 0). Later we use this predicate with arguments y and 2y where y 
is declared to be a positive number. The implicit intention of the author of the 
text is of course that every positive number is non-zero and hence the predicate 
may be used. This implicit intention must be made explicit in the type theory. 
Fig. 7 shows how we can do this. The definition of divides which is under the 
condition m yf 0 is translated to a definition which has one extra argument, 
h : (m yf 0) which is a proof of the fact that m is non-zero. Adding extra 
proof parameters to a definition is one of the standard ways to represent par- 
tial functions in type theory and dates back to the Authomath project (see [3], 
p.709-710). 

Next, we need to translate the instance divides(?/, 2y) in the last statement in 
Fig. 6. As the definition of divides prescribes, we need to provide a proof that y 
is non-zero. This proof in principle should be constructed using the assumption 
that y is a positive number. So we introduce a meta- variable m representing this 
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m,n ■. N\ 
m / 0 

divides(m, n) := 3k-.N{n = km) 
positive Adjn-. jv(0 < n) 

number N ) 
y ; positive number 
divides(y, 2y) 



Fig. 6. Conditional definitions 



m,n : N 
/i : (m / 0) 

divides(m, n, h ) := 3k:N{n = 
n : iV| 

positive(n) := (0 < n) : Prop 
number := N : Set 



km) : Prop 



y : number] 
h : positive(j/) 
m[y, h] := open : (j/ / 0) 

Li[y,h] — open : divides(j/, 2t/, m[y,h] ) 



Fig. 7 . Handling of conditional definitions 

proof. Note that m is introduced in the same context as the occurrence of divides 
and hence it is in the scope of the assumption h : positive(y). 

The actual proof of the fact that y ^ 0 follows from 0 < y is implicit in 
the proof and this is reflected here by the introduction of the meta-variable. 
We prefer to leave a proof open instead of using other methods like subtyping, 
decision procedures, etc. The use of such methods is not prevented or denied, 
we have just delayed their use and left it to the dedicated theorem prover that 
will work with the text with incomplete proofs. 

3.3 The Need for Unification 

As we explained above, in certain cases we may obtain objects which depend on 
totally or partially unknown proofs. Due to the strong typing, often we will need 
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to check whether two objects are equal. Since every occurrence of a constant 
declared under a condition gets a fresh meta-variable as a representation of the 
unknown proof of the condition, we will find out that many constants are not 
equal. 

For example, Consider the following declaration of the inversion function x~^ 
for non-zero x and the goal to prove that x~^ = x~^: 



X : R 



X : R\ 


h : {x 0) 


X 0 


inv{x, h) R 

mi[a;] := open : x ^ 0 
m 2 [x] := open : x ^ 0 

Li[x] := open : inv[x , mi[x\] = inv[x,m 2 [x]] 


inv{x) := . . . 
inv{x) = inv{x) 



The translation of the WTT text is shown to the right. Looking at the WTT 
text, one may think that to solve the goal a simple reference to the reflexivity 
of equality is enough, but in fact such an approach will fail, since the terms 
inv[x,mi[x]] and inv[x,m 2 [x\] are not /3-convertible. Using unification however 
we could find out that to make them convertible, it is enough to have m 2 [x\ := 
mi [x] . 

This simple example shows how the introduction of proof parameters to ob- 
jects may break the strong typing rules of the target type theory. Such problems 
are unavoidable however and one may need to use a form of matching or unifi- 
cation in order to eliminate (part of) them. 

3.4 Set Comprehension, Adjectives and Function Spaces 

In WTT we can form nouns by means of application of adjectives to existing 
nouns or to create sets by set comprehension which effectively introduces a kind 
of subtyping in the system. Consider for example the WTT text in Fig. 8. We 
have a second order function on the positive numbers whose type is defined 
using adjectives and set comprehension. One way to deal with such functions 
could be to extend the approach from Section 3.2 as shown in Fig. 9. The idea 





positive := Adjn-.N{0 < n) 
number := N 1 




f : (positive number ^ positive number) ^ Setk-.NiQ < k) 




/(Aa: : positive number.®) > 0 



Fig. 8. Adjectives and function spaces 
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positive ~ Adj„:jv(0 < n) 




/ : ng:{nx:N.{0 < x) ^ A^). 7777 : (77a; : iV.(0 < a:) ^ 0 < g{x,h)).N 


F : ng-.{nx:N.{0 < x) ^ iV). 7777 : (77a: : W(0 < x) ^ 0 < g{x,h)).0 < f{g,H) 


Li := open : f{Xx:NXh: (0 < x).x){Xx:NXh: {0 < x) .h) > 0 



Fig. 9. 



is to represent functions whose range is a comprehended set into two functions. 
The first one produces the value and the second the proof that the value of 
the first satisfied the conditions. If such a function is given as an argument, the 
translation would expect two arguments, again one that produces the value and 
a second for the proof obligation (see Fig. 9). 

This approach is technically complicated and it is not yet clear whether it is 
universally applicable (i.e. whether it is possible to do it automatically). Hence 
an implementation may have to limit the use of adjectives and set comprehension 
in function formation. We also have to keep in mind that the translation very 
much depends on the choice of a target type theory and hence on the possibilities 
to introduce subtyping there. 



4 Prom Flag Notation to Typing Judgments 

The flag notation that we use to represent the translation of WTT books into 
type theory can be converted in a straightforward manner into the usual nota- 
tion with typing judgments if the target typing system supports parameterized 
definitions and meta-variables. Such a judgment has the form 

r'r M ■. A 

where T is a context containing declarations and definitions, M is a term and 
H is a type. It should be read as ‘in the context F, the term M has type A. 

Given an OTT book in flag notation, we convert every line of the book into a 
parameterized definition or a declaration of a constant or a meta- variable. The 
parameters form a local context that is constructed by collecting all declarations 
in the flags under which the current line is situated. For example, in Fig. 10 we 
see that a primitive constant (iV) is translated into a parameterized declaration, 
a definition line (divides) is translated into a parameterized definition and open 
definitions (m and Li) are mapped into declarations of parameterized meta- 
variables. 

This straightforward translation of flagged derivations into conventional judg- 
ment form allows us to define that a well-formed flagged derivation is well-typed 
if and only if its translation is derivable as a conventional judgment. Actually, 
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Flag Notation 



N := prim : Set 

m,n : N 
h : {m ^ 0) 

divides(m, n, h) := 3k:N{n ~ km) : Prop 
n : iV| 

positive(n) := (0 < n) : Prop 
y : number 
h : positive(j/) 
m[y,h] ■- open : (t/ / 0) 

Li [y, h] := open : divides(j/, 2y, m[y, h]) 



N : Set, 

divides(m :N,n:N,h: (m 7 ^ 0)) := 3fc,iv(n = km) : Prop, 
positive(n : N) := (0 < n) : Prop, 

Conventional Notation m[y : N,h: positive(j/)] : {y 7 ^ 0), 

Li[y : N,h: positive(i/)] : divides(j/, 2y, m[j/, /i]) 
h 

Set : Type 



Fig. 10. A text in flag notation and its translation to a conventional judgment form. 
To distinguish between constants and meta-variables, we denote the former by c(. . .) 
and the latter by m[. . .] 

what we need is only that the context of the judgment is valid. This is the reason 
why we have Set: Type after the turnstyle (h) sign. 



5 Conclusions and Further Research 

We discussed, using examples to illustrate our approach, how a CML-text can be 
transformed stepwise into (1) a formal WTT-text, (2) a version in type theory 
with open terms and (3) stepwise, into a fully formalized text in type theory. We 
argued that the sketched formalization and proof construction is ‘natural’ in the 
sense that a human can easily follow the path and do the steps needed, possibly 
with active help of a proof assistant. Moreover, we have the conviction that the 
proposed approach increases the reliability of the formalization, as regards its 
conformity to the intentions of the mathematical author. 

As topics of future work we can mention further investigation of the trans- 
lation of WTT into Type Theory with open terms, including a prototype im- 
plementation. Such an implementation will gives us more understanding of the 
practical feasibility of the approach we advocate here. 
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Abstract. This paper reports on refinements and extensions to the MathLang 
framework that add substantial support for natural language text. We show how 
the extended framework supports multiple views of mathematical texts, including 
natural language views using the exact text that the mathematician wants to use. 
Thus, MathLang now supports the ability to capture the essential mathematical 
structure of mathematics written using natural language text. We show examples 
of how arbitrary mathematical text can be encoded in MathLang without needing 
to change any of the words or symbols of the texts or their order. In particular, 
we show the encoding of a theorem and its proof that has been used by Wiedijk 
for comparing many theorem prover representations of mathematics, namely the 
irrationality of \/2 (originally due to Pythagoras). We encode a 1960 version by 
Hardy and Wright, and a more recent version by Barendregt. 



1 On the Way to a Mathematical Vernacular for Computers 

Mathematicians now use computer software for a variety of tasks: typing mathematical 
texts, performing calculation, analyzing theories, verifying proofs. Software tools like 
Mathematica have been refined through many years of development. Research in math- 
ematics, logic, and computer science has led to computer algebra systems (CAS’s) and 
theorem pro vers (TPs). Languages like OMDoc [14] show good promise of having a 
universal way to share CAS and TP data in a mathematical software network [22]. 

Nevertheless, ordinary mathematicians still write mathematical knowledge (MK) 
using the traditional common mathematical language (Cml) and typesetting tools like 
MTeX. Cml is mature and capable for human communication of mathematics, but un- 
fortunately is difficult to computerize in a way that captures its essential structure. 

We believe this is largely because existing computer MK representations either fail to 
capture the mathematical structure of natural language as used in mathematics or require 
writing in a rigid format [9] . Mathematical typesetting systems like fflgX fail to capture 
the mathematical structure of both natural language text and symbolic formulas. Existing 
computer mathematics systems that capture mathematical structure either (1) do so for 
symbolic formulas but not natural language sentences and phrases (e.g. OpenMath or 
computer algebra systems), (2) handle natural language text via very complicated type 
systems (e.g. GF [18]), (3) require full formalization (e.g. Mizar [19] or other proof 
systems), or (4) otherwise restrict mathematicians’ freedom to edit and display their 
texts in the form that best meets their needs and desires. 

Theoretical approaches to this issue include De Bruijn’s Mathematical Vernacular 
(MV) [4] and the recently developed Weak Type Theory (WTT) of Kamareddine and 
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Nederpelt [12], both of which strive toward a formalism that captures the structure of 
mathematical text while remaining close to the mathematician’s original text. 

Carrying the work of MV and WTT forward, we have been building MathLang, 
a framework for encoding mathematical texts on the computer. MathLang’s heart is 
a formalism capturing the important mathematical structure of mathematical writing 
while keeping the flexibility of the traditional common mathematical language (Cml). 
MathLang aims to interface computer mathematics systems with mathematicians. 

MathLang analyses all mathematical texts into two interleaved parts, one for the 
natural language and one for the symbolic structure. The natural language part represents 
the text as the mathematician expects to view it. The symbolic part is automatically 
checked for structural correctness and contains enough semantic information to support 
further automatic manipulation by other available computer mathematics tools. 

MathLang’s design is constrained by the desire to balance the needs of ordinary 
mathematicians in writing MK with the needs of automated computer manipulation of 
MK. To support mathematicians, MathLang seeks to be (1) expressive, so it can handle 
all kinds of mathematical mental constructs, (2) flexible, so that ordinary mathematicians 
will not find it awkward to use, and (3) universal, so that it covers many branches of 
mathematics and is adaptable to new ones. To support computer manipulation, MathLang 
seeks to be (4) relatively unambiguous, so that automated processing will often be 
possible without human interaction, (5) sensibly organized, so that most desired ways of 
browsing the data will not be difficult, and (6) automation-friendly, to facilitate further 
more complex computations. 

The language formalism of MathLang has three main features. (1) A symbolic struc- 
ture. MathLang encodes mathematical texts via a symbolic syntax. A small set of gram- 
matical constructions allows encoding the reasoning structure of texts. The symbolic 
structure is helpful for further encodings and translations. (2) A Cml layer. MathLang 
can coat the symbolic structure of the text with natural language information that sup- 
ports a Cml view of the text, like the kind of visual output that could be generated if 
it was written in but also keeping the full underlying computerized structure. 

(3) Automatic checking of basic grammatical conditions of the reasoning structure. 
MathLang encodes the reasoning structure of a texts. A set of typing rules checks basic 
grammatical conditions using weak types, thus validating the good formation of the 
text at a grammatical level. It is very important that this checking does not require full 
formalization or committing to any specific foundation of mathematics. 

In earlier work [13], we introduced MathLang, defined its XML-based concrete 
syntax, implemented a weak type checker, and tested the encoding of substantial real 
mathematical documents. MathLang’s Cml layer is new and is reported here for the first 
time. MathLang’s symbolic structure and automated checking have had minor improve- 
ments since first reported, mainly to better support the integration of natural language 
text. 

This article introduces MathLang’s Cml support in the context of explaining how 
the design of MathLang is evolving so that it can balance the needs both for the encoding 
to easily support desired computations and for the representation to be close enough to 
the thinking of the mathematician. Section 2 presents the MathLang philosophy while 
the later sections explain the capabilities of MathLang via example encodings. Although 
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we are currently testing MathLang by encoding two large mathematical books [15, 
10], this article presents encodings of shorter examples, fully developed in MathLang. 
Section 3 presents an example (translated earlier into WTT) and shows its encoding in 
MathLang via both the symbolic and Cml views automatically derived by MathLang. 
Section 4 presents a bigger example: Pythagoras’ proof of the irrationality of s/2. We 
chose this proof because it has been previously used by Wiedijk as a universal example 
of proof encoding for theorem provers [20]. We encode two informal versions of this 
proof in MathLang: an earlier one due to Hardy and Wright as well as a more explicit 
(but still informal) one due to Barendregt. For all 3 example encodings presented in this 
paper, the Cml view illustrates that (unlike WTT) MathLang indeed preserves all the 
original text, including the natural language part. 



2 MathLang ’s Philosophy and Evolving Design 

MathLang follows these goals: 

1. Remain close to Cml as used by mathematicians to write mathematics. 

2. Act as a formal structured style which can be plugged into CAS’s, TPs and other 
mathematical software systems. 

3. Provide users of mathematics with much needed help in getting the original math- 
ematical text into the computer by providing both a formal view of the text, and a 
natural language view. The formal view of the text is exactly its symbolic part and 
is passed to an automatic weak type checker which tests the structural validity of 
the text. The natural language view is automatically generated from the formal view 
and looks exactly like the original text. 

We believe MathLang is the first framework which satisfies all the goals above. 
Some systems, Mizar [19] being the best example, have impressive libraries that show 
that much mathematics can be computerized and formalized, but they are not yet widely 
used by mathematicians. Abstract languages like MV and WTT are strongly based on 
goal 1 , but fall short on goals 2 and 3, because neither provides any computer help, nor an 
automatic type checker to check the structural correctness of texts, nor is there a method 
yet of taking the translation of an original text in MV or WTT and deriving from the 
translation a text that looks exactly like the original one. Although MathLang has a type 
system which is an extension of WTT with flags and blocks, it goes well beyond MV 
and WTT by also working as a computer system which will communicate with other 
computer systems via XML and XSLT and will offer the user software help. Moreover, 
the merge between the abstract and the software could not have worked well to provide 
a view that looks so much like the original text, without both (1) the careful separation 
of texts into a natural language part and a formal part and (2) a careful interleaving of 
both parts. 

Below we describe the framework MathLang following its three main features listed 
in Section 1 . We first describe the syntax and grammar of MathLang, then we describe 
how the Cml layer has been designed, then we explain the value that is added by Math- 
Lang’s type system compared to a normal Cml encoding. 
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2.1 The Symbolic Structure 

The MathLang symbolic language [13] has a strict grammar that allows one to describe, 
with a small set of constructions, any feature that composes the reasoning content of a 
mathematical text. 

MathLang’s Grammar. As in MV [4] and WTT [12], an entire MathLang document 
is called a book. It is composed by a set of blocks, flags and lines. Blocks and flags 
are themselves composed by sub-blocks, flags and lines. A block highlights a piece 
of text as a coherent entity. It could be a section, a proof or a subproof, an example or 
any structure that the author wants to identify. Local constants are defined within a 
block (see below for more explanation). A flag declares variables (again, see below) 
and makes assumptions that will hold on a piece of text. A line is an atomic step of 
reasoning. As in common mathematical texts, a line could either make a new statement 
in the theory or define a new symbol (the sentence level groups these two possible 
kinds of line). Books, blocks, flags and lines compose the discourse level. 

Four constructions are defined in MathLang to write expressions that will be the 
material of assumptions, declarations, definitions and statements from the discourse 
level. A variable instance refers to an already declared variable. A constant call 
uses a defined constant by referring to its definition and, in the case of a parametrized 
constant, by instantiating it. Binding an expression and a new variable is also possible 
with one of the many binders of the language. The last construction attributes an 
adjective to a noun to refine its meaning (again, see in the following for explanation 
on adjectives and nouns). These four constructions make up the phrase level. 

Symbols used in MathLang texts are used in the atomic level. They could be of 
three kinds: variables that are an abstraction of a mathematical object, constants that 
are parameterizable shortcuts for mathematical objects, and binders. 

Grammatical Categories. Any construction of the phase level is part of a specific 
grammatical category depending on the sort of the mathematical object described. In 
an obvious sense it depends on the symbol used to construct the expression in question. 
There are five of them: terms for elements designing a mathematical object, sets for 
sets of objects, nouns for kinds of mathematical objects, adjectives for elements that 
gives some attributes to a noun, and statements for expression that are considered 
as structurally valid statements. This grammatical information will be used by the 
MathLang type system (see Section 2.3). 

Concrete Syntax. The concrete syntax of MathLang uses XML. XML-MathLang texts 
have level-based structure and contain grammatical information for each symbol. 



2.2 The Layer 

A MathLang author separates a CML-text into its natural language part and its symbolic 
part, saving the natural language part for coating purposes later, and translating the 
symbolic part into XML-MathLang. This XML-MathLang text is then passed into the 
automatic type checker of the symbolic framework to test its structural well-formedness 
(see Section 2.3) and thus implicitly also the original text. Figure 1 informally compares 
this encoding approach to others. 

Cml. The overall document is in an informal encoding. 
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OMDoc’s Approach. A slightly formal structure (dashed triangle) covers the entire 
document. Cml texts are spread all around the document. OpenMath objects are used 
for formal dehnitions (<FMP> tag). Informal definitions (<CMP> tag) are text with 
embedded OpenMath formulas. 

WTT. The overall document is a formal encoding. Like N.G. de Bruijn’s MV and Z. Luo 
and P. Callaghan’s Mathematical Vernacular [16], WTT is a theoretical language and 
does not have any natural language representation. 

MathLang’s Approach. A computerized structure covers the entire documents. Pieces 
of Cml transformation procedures are attached to nodes of the document’s skeleton. 
TPs’ Approach. The document is a fully formal data. Usually, Cml explanations are 
separately given (dashed blobby shapes). The natural language is produced with 
generic computations according to some structured text given by the programmer. 
(We consider here the generation of natural language texts from Coq [5], the design 
of an electronic library of mathematics [1], the Mo WGLI project [8], work to interface 
Coq with [2], and the documentation system of FoC [17].) 

Figure 2 shows that the original Cml text is hrst divided into a symbolic part and a 
natural language part and that afterward, the full original text can be retrieved, as well 
as a fully symbolic part which can be passed for further processing. We are currently 
using XSLT to express the transformations to Cml. We are considering the use of the 
Grammatical Framework [ 1 8] for its expressiveness as a replacement of XSL. A possible 
intermediate stage from CML-texts to fully formalized texts (the “later computations” 
in Figure 2) could be to use the Mathematical Proof Language [3], a language between 
informal and formalized mathematics. 




Fig. 1. Approaches. Informal data is represented by blobby shapes (P). Computerized and more 
formal data is represented by triangles (A) 



Rendering tools have been developed using XSLT to generate representations of 
MathLang documents. All the examples of this article have been automatically generated 
using these tools which work as follows given an XML-MathLang text: 

- Display the information in symbolic structural view. 

- Display the information in Cml form (if it contains a natural language coating). 
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Fig. 2. Translation process 



2.3 MathLang Typing 

From this grammatical information given in the writing down of MathLang document, 
computerized analysis is possible. It gives some properties about the coherence of the 
text. This is done by assigning weak types to each grammatical category and construction. 
This weak typing remains at a grammatical level. A type theory could then be used 
to check the text. If a book is considered as a valid book after typing, it means that 
variables are well declared before being used and constants are well used according to 
their definitions. Because this analysis remains at a grammatical level, it therefore does 
not deal with the logical truth or validity of the text. 

We developed an automatic weak type checker which analyzes the coherence of 
the XML-MathLang text. This automatic type checker, when given a text in XML- 
MathLang, checks whether the reasoning structure of the text is valid or not. In the latter 
case, an error message gives the reason of failure. 

3 A Working Example 

The translation of a mathematical text into a MathLang document is done by a human 
assisted by a computer. The MathLang writer should have a mathematical background 
to follow the reasoning of the mathematician author of the original text. Moreover, the 
MathLang writer needs to have skills in computer science to encode the document into 
the MathLang XML syntax. This last requirement would be avoided in the future by the 
development of a dedicated editor for MathLang (see Section 5). 

3.1 The Translation Process 

Four actions compose the translation process of a Cml text into MathLang with pre- 
sentation directives. The first two are to be done by the MathLang user. They are repre- 
sented by the Translation arrow of Figure 2. The last two are initiated by the user 
and are automatically executed by MathLang’s framework. These are the Automatic 
computations of Figure 2. 
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Translating. This is the main work done by the user: it reveals the reasoning structure 
of the original text and encodes it into MathLang. These do not require more work 
than a normal study of the text. The writer just needs to unfold implicit information 
form his understanding of the Cml text (see Section 3.2). 

Adding Natural Language. This is a crucial stage of the translation. It will not influence 
the deep MathLang encoding of the text and so will not change its validity. But it 
will make the MathLang document as readable as the original Cml text. Because this 
stage is independent from type checking, this information could be added during the 
early translation of a piece of text or after the validating stage. 

Type Checking. This stage is an automatic computation. The MathLang framework 
has a built in type checker which takes a MathLang XML document and checks its 
structural validity. The type checking of a MathLang XML document returns true if 
the program goes through the document without finding any problem. Otherwise the 
MathLang type checker will point an element of the document where an error has 
been found. The user will then need to fix it and recall the checker again. 

Producing the Cml Output. This stage is again fully automatic. It uses several XSL 
transformations to generate a Cml text with colour annotations showing the weak 
types in the document. This process takes into account the presentation information 
given by the author to generate an output which is close to the original Cml text. 

To illustrate the steps to be taken by a MathLang user, we will explain the two first 
stages with a concrete example. We give the original text to be encoded, a representation 
of our MathLang encoding, and the Cml output obtained from it. We use grey scale to 
show the belonging of text parts to a grammatical category. This helps to show in the 
Cml MathLang output, the underlying structure of the MathLang encoding. Figure 4 
contains the grey scale coding we are using in this paper. 

We took our example from article [12]. By using the same example we aim to show 
what improvements MathLang makes over WTT. WTT was a theory describing a type 
system for the first level of formalization of mathematical texts. The language description 
was not precise enough to be used and no implementation of its ideas were available. 
MathLang reuses this type theory in its implementation. New constructions have been 
added as explained in [13]. 

3.2 The Example 

Our example is a definition which defines the difference quotient of a function, explains 
what is a differentiable function and then states that \/\x\ is not differentiable at 0. The 
original Cml text is given by Figure 3. Figure 5 shows our MathLang encoding and 
Figure 6 the output we get. 



Definition 1. Let h ^ 0, let f be a function from AtoM., a £ A and a A h £ A. Then 
difference quotient off in a with difference h. We call f differentiable 
at a if limh^o exists. The function \/[x[ is not differentiable at 0. 



Fig. 3. Difference quotient example: original text 
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Fig. 4. Grey scale coding 




Fig. 5. Difference quotient example: symbolic structural view of MathLang 



Translating. The original text is titled “Definition” and contains three steps. We 
encode it by a block (with indices { 1}) to reflect the grouping of the overall definition. 
Then to each step corresponds one line. The first one (numbered 1) stands for the defi- 
nition of the difference quotient and will be a definition line in MathLang. The second 
(numbered 2) will again be a definition line defining a new notion: differentiable. The 
last step (numbered 3) that establishes that i/jxj is not differentiable at 0 is encoded by 
a statement line. 

The Definitions. In the text, we notice that both definitions have some elements in com- 
mon. They use the same set A, the same function / and the same element a of A. These 
are variables. To put them in common in the MathLang document we use the flag con- 
struction that introduces context elements for several lines. In our case three variables 
are declared for the first two lines. The first definition also requires the declaration of 
the variable h together with two assumptions: h 0 and a -F /i is in 2l. 

We notice that the flag contains three elements. In the original text only four context 
elements are visible (the first sentence of Figure 3). The MathLang grammar forces one 
to strictly declare any variable. A : SET that declares a set variable A is an example of 
implicit declaration which is revealed by MathLang. 
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Fig. 6. Difference quotient example: Cml view of MathLang 



With these contexts enunciated, we give our two definitions. Here again some infor- 
mation will become explicit. Constant parameters should correspond to the current set 
of declared variables: h. A, a and / for the difference quotient and A, f and a for differ- 
entiable notion. The first definition uses some constants that we consider to be defined 
earlier on. The second definition uses the existential binder to state that a limit exists and 
that its value is the limit of the differential quotient when h tends towards 0. Our choice 
here was to reuse the constant previously defined difference quotient instead 
of writing again the equation. 

The Statement. The last line with an empty context states that the function \/\x\ (encoded 
with the A binder) is not differentiable at 0. This expression uses the newly defined 
constant differentiable. 

Adding Natural Language. The block including the entire text is represented with 
a definition HTj^X environment. The sentence “Let |T], [^.” stands for the flag of our 
encoding where Q] and are the declarations of / and a. An empty little box in Figure 6 
shows that an implicit declaration (the set A) took place. We do the same for the context 
of line 1 . The order of declarations and assumptions was changed from Figure 3 to 
Figure 6 on purpose to show the boxes that correspond to the flag and to the context of 
the first line. “Then Q] is the [T| of [^1 in ^ with difference is the template for our 
first definition. |T] being the expression of the definition, the constant’s name, [ 3 ] the 
constant’s fourth parameter, the third one and ^ the first one. 

These associations that link one construction of the language to a natural language 
template could either be defined globally or locally to the document. One association 
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could be reused at different positions. They are defined using XSL with some MathLang 
specific commands to easily refer to the information contained in the encoding. For 
example a unique command is used to colour the pieces of text according to their gram- 
matical categories. For example, the presentation information for the line numbered 1 
is as follow. 

<template output="cml . tex" kind="xsl"> 

<categ kind="par" boxed="no"> 

<xsl : apply- templates select= "context" /> 

<xsl : text>Then </xsl:text> 

<xsl : apply- templates select= " expression" /> 

<xsl:text> is the </xsl:text> 

<xsl : apply- templates select= "constant" /> 

<xsl:text> of </xsl:text> 

<xsl : apply- templates select="parameters [4] "/> 

<xsl:text> in </xsl:text> 

<xsl : apply- templates select="parameters [3] "/> 

<xsl:text> with difference </xsl:text> 

<xsl : apply- templates select="parameters [1] "/> 

<number/> 

</categ> 

</template> 



This information is a mix of XSL standard elements and MathLang specific ones. A 
first process will transform all these presentation data that coat the document to produce 
one single XSL file specific to the document in question. The second process simply 
consists of applying these transformation to the document itself. 



4 Pythagoras’ Proof of Irrationality of a/2 

In this section we give the CML-MathLang view of two versions of Pythagoras’ proof 
of the irrationality of s/2. We chose this proof because it has been previously used by 
Wiedijk as a universal example of proof encoding for theorem provers [20,21]. Both 
original versions are included in [20]. The first one is an informal version written by 
G. H. Hardy and E. M. Wright (see Figure 7). Section 4.1 is the Cml view of our 
translation into MathLang. The second one is a more explicit proof written by Henk 
Barendregt. We give the Cml view of our MathLang translation in Section 4.2. 



Theorem 1 (Pythagoras’ Theorem). \/2 is irrational. 

Proof. If s/2 is rational, then the equation 

a = 2b 

is soluble in integers o, b with (a, b) = 1. Hence is even, and therefore a is 
even. If a = 2c, then 4c^ = 2b^, 2c? = b^, and b is also even, contrary to the 
hypothesis that (a, b) — 1. 



Fig. 7. Proof of the irrationality of \/2 
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4.1 The Informal Proof of Hardy and Wright 



Theorem 1 (Pythagoras’ Theorem). 



\j^\ irrational 



Proof. The traditional proof ascribed to Pythagoras runs as follow| 
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4.2 A More Explicit Informal Proof by Barendregt 



Lemma 1. 
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Corollary 1. 
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4.3 Discussions 

More or Less Explicit Texts. The small set of grammatical constructions of MathLang 
gives all the material needed to express reasoning of different levels of precision. Both 
versions given here follow the same kind of structures in their demonstrations. Small 
steps leading to bigger ones. New statements in a certain context and definitions of new 
symbols. This is what MathLang is designed for: encoding these simple demonstra- 
tion constructions into a structured document that eases computation. In both cases the 
MathLang encoding follows the reasoning structure of the text. Simple transformation 
procedures are then given to get the original text in return. These two versions of the 
same proof show the expressiveness of MathLang: we have used the same language to 
write a non precise proof as well as a fully explicit one. From this encoding of the proof 
in MathLang we get both the original text and the computerized document. 

Moving from MathLang to Other Encodings. As we said before, the symbolic structure of 
MathLang texts eases both the automatic computations on the text and further translations 
to other languages. To illustrate this we have translated Barendregt’s version of the proof 
into OMDoc/OpenMath. 

The translation process is the same as the one carried out to obtain the Cml view 
of MathLang documents. We spread the document with transformation information. 
This led to a big program that transforms automatically the MathLang document into 
OMDoc/OpenMath. In this transformation <CMP> (informal) and <FMP> (formal) OM- 
Doc’s tags could easily be informed. The first one using the same process as the one 
carried out to obtain a Cml view of the MathLang text. The second one by using the sym- 
bolic structure to obtain OpenMath formulas. The third part of this translation consists 
in mapping the MathLang basic structures into OMDoc constructions. 
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For example, our MathLang translation of Barendregt’s version of the proof consists 
of one line followed by one block, one line and one block. The first line being the 
definition of the lemma, the first block its proof, the second line (numbered 25) is the 
definition of the corollary and the second block its proof. In OMDoc the lines 1 and 25 
are <assertions> and the blocks are <proof>. The predicate P defined in the 
proof of the lemma (line 2) is a symbol definition (<symbol>) in the overall proof 
(<theory> in OMDoc, book in MathLang). 

We compared this translation, that leads from a Cml text to an OMDoc document via 
a MathLang document, to a direct translation from Cml to OMDoc. The direct translation 
seems to be quicker but the one via MathLang has three advantages. 

- The MathLang document is checked by the MathLang weak type checking. This 
validates the good formation of the structure of the document. Such an analysis does 
not exist for OMDoc and OpenMath. 

- OMDoc has a formal (<FMP>) and an informal (CMP) tag for data. There are no 
requirements in OMDoc to have them both informed. The computerisable content of 
an OMDoc document depends on the author. In MathLang the main skeleton of the 
document fully uses symbols (similar to OMDoc’s formal data), the natural language 
is added on top of this structured content. A MathLang-text always provides a. formal 
content that could be forgotten in OMDoc. 

- This structured content is encoded using a small set of MathLang constructions. 
These simple grammatical constructions guide the author in the translation process. 
It is then easier with this guiding process to obtain well structured OMDoc formal 
data by translating first into MathLang than directly into OMDoc. 



5 Future Works 

We described in this paper how we encode mathematics using MathLang and how we 
produce a Cml view of this encoding. Our main future work is to ease the input of data 
inside the MathLang framework. Currently one requires skills in computer science to 
write a MathLang document. We are currently developing a user interface for MathLang 
based on the scientific editor Tj 3 X^,^,, 5 . 

As we said earlier in this paper we are starting and planing to extend the current 
language and framework. We aim to do it by making a use of the Grammatical Framework 
of A. Ranta and by moving to a second level of MathLang encoding which will include 
more logic and semantic. 



6 Conclusion 

By providing at the same time a computable encoding and a simple structure to produce 
readable output, our language MathLang tries to fill the gap between printed mathemat- 
ical texts and mathematical softwares. The main problem mathematicians face when 
using formal systems is that it is very difficult, even for an expert, to find her way in a 
formal proof written by someone else. As described in this article, our system provides 
a direct correspondence between a symbolic structure and a Cml view of a text. The 
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original mathematical document is wisely partitioned between a natural language part 
and a symbolic part. The symbolic part can be used in more formal computations on the 
original text. This is how we imagine what could be the new mathematical vernacular 
for computers. 
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Abstract. Automated knowledge management techniques critically de- 
pend on the availability of semantically enhanced documents which are 
hard to come by in practice. Starting from a detailed look at the moti- 
vations of users to produce semantic data, we argue that the authoring 
problem experienced by MKM is actually an author’s dilemma. An anal- 
ysis of the content authoring process suggests that the dilemma can 
partially be overcome by providing authoring tools like invasive edi- 
tors aimed specifically at supporting the content creator. We present 
the CPoint application, a semantic, invasive editor for Microsoft Pow- 
erPoint, geared towards the OMDoc MKM format. 



1 Introduction 

Knowledge management technologies are concerned with recovering the content 
and semantics from documents and exploiting it for automation with an emphasis 
on web-based and distributed access to the knowledge. The interest in applying 
knowledge management tools to mathematics (Mathematical Knowledge Man- 
agement, MKM) is based on the fact that mathematics is a very well-structured 
and well-conceptualized subject, which makes the knowledge management task 
simpler and more effective. 

Currently, the field of MKM focuses on representation formats for mathemat- 
ical knowledge (MathML [3], OpenMath [7], or OMDoc [19], etc.), mathemat- 
ical content management systems [12, 1, 2], as well as publication and education 
systems for mathematics [9,23]. 

While the system prototypes showcase the potential added value of explicitly 
representing the content and semantics of mathematical knowledge, they have 
failed to take off in terms of actual deployments. The main bottleneck seems 
to be the lack of large-scale, high-quality corpora of mathematical knowledge 
marked up in the respective MKM formats and the effort involved in creating 
these. Conventional wisdom (aka. “hope”) in MKM is that the added-value ap- 
plications based on semantic annotations will create a stimulus that will entice 
common users to invest time and effort into this exciting new technology. But the 
community experiences at the moment, that it is not yet sufficiently tempting. 
We will call this the MKM authoring problem. 

In this paper, we will take a detailed look at the motivations of users to 
create MKM content and show that the MKM authoring problem is actually 
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an author’s dilemma. We will then develop the concept of an invasive editor as 
a (partial) solution to the MKM authoring problem and present the CPoint 
application, a semantic, invasive editor for Microsoft PowerPoint. 



2 The Author’s Dilemma 

For a user of MKM material, the motivation for preferring semantically rich data 
is simple: explicit document structure supports enhanced navigation and search, 
semantic markup yields context and search by content. Furthermore, the higher 
the degree of semantic structure, the more added-value services can feed on the 
material, the higher the benefit for the user. 

2.1 What is the Author’s Dilemma? 

For a document author, the cost of creating a document is a priori proportional 
to the depth of the markup involved (assuming that the markup quality is cost- 
independent in an ideal world). However, once the markup quality passes a 
certain threshold which supports flexible reuse of fragments, document creation 
costs may actually go down as they are dominated by the cost of finding suitable 
(already existent) knowledge elements. Thus, the author is interested in a high 
reuse ratio, provided that retrieval costs are not prohibitive. The benefits are 
obvious for the author who has the opportunity to reuse her own content modules 
frequently, but the real payoff comes when she is part of a group of individuals 
that share content objects and knowledge structures freely. But why should an 
author share her content modules with others, who could make use of them 
without contributing to the common share of materials? 

Cooperation is often analyzed by means of a non-zero-sum game called the 
Prisoner’s Dilemma (see [4]). The two players in the game can choose between 
two moves, either ’’cooperate” or ’’defect”. The idea is that each player gains 
when both cooperate, but if only one of them cooperates, the other one, who 
defects, will gain more. If both defect both lose, but not as much as the ‘cheated’ 
cooperator whose cooperation is not returned. The prisoner’s dilemma is meant 
to study short term decision-making where the actors do not have any specific 
expectations about future interactions or collaborations. 

The analogy to the document author’s situation is apparent: if the author 
decides to invest his time and effort and others contribute as well, everyone 
profits tremendously from this synergy of cooperation. On the other hand, if 
just the author works on semantic markup, then he will gain nothing in the 
short run (but some in the long run). So, we can rightfully call it the author’s 
dilemma. 

In the prisoner’s dilemma, if the decision-makers were purely rational, they 
would never cooperate as they should make the decision which is best for them 
individually. Suppose the other one would defect, then it is rational to defect 
yourself: you won’t gain much, but if you do not defect you will have all the work. 
Suppose the other one would cooperate, then you will gain (especially in the long 
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run) whatever you decide, but you will gain more if you do not cooperate (as 
you don’t have to invest your time and effort), so here too the rational choice 
is to defect. The problem is that if all actors are rational, all will decide to 
defect, and none of them will gain anything. If we assume MKM authors to be 
rational, then we anticipate their non-cooperation. The MKM authoring problem 
is a consequence of the author’s dilemma. 

In order to tackle the author’s dilemma we investigate the central assumption 
of the prisoner’s dilemma that the actors do not have “specific expectations about 
future interactions or collaborations”. 

One way to get around the author’s dilemma is to build or strengthen these 
expectations, for example by establishing targeted, cooperating research groups, 
open source and open content licensing, or citation indexes. Such measures^ may 
well tip the scale towards cooperation and would therefore be a very worthwhile 
contribution to the MKM authoring problem. 

In this paper, we will single out the ’real payoff’ benefit, show why this 
argument doesn’t constitute a specific expectation in the dilemma scenario, and 
finally dissolve the author’s dilemma by changing its input parameters (costs and 
benefits). In particular, we will concentrate on a single author and the content 
authoring process. 

2.2 The Content Authoring Process 

The key intuition in MKM formats is to make semantic structures that are 
implicit in conventional forms of communication so explicit that they can be 
manipulated by machines. This explication can happen on several levels: for- 
mats like MathML [3] or OpenMath [7] allow to mark up the structure of 
mathematical formulae, formats like CNXML [10] mark up the document struc- 
ture and allow to classify text fragments in terms of mathematical forms like 
“Definition”, “Theorem”, “Proof”, etc. Formats like the logic-based Case [11] 
or the development graph format [16] allow to structure mathematical knowledge 
into graphs of so-called “Theories” , which make semantic relations (like reuse of 
content, semantic (in)dependence, and interpretability) explicit and available for 
computer-supported management. Finally, formats like OMDoc [19] attempt to 
combine all of these aspects of MKM into one integrated representation format 
for mathematical knowledge. 

The explication of structure allows for a new authoring process, the con- 
tent authoring process. In conventional document formats like DTeX, the 
document- and knowledge structure is inseparable from the atomic content (para- 
graphs of text, mathematical statements, ...). Therefore they have to be au- 
thored at the same time, with the exception of copy-and-paste techniques that 
have become available by electronic document formats. With the advent of se- 
mantic markup techniques, hypertext, and the distribution medium of the Inter- 
net, users are enabled to aggregate knowledge fragments (self-authored or from 
other sources) without losing the semantic context, or having to adapt notations: 



^ See the Connexions project for community-building efforts in this direction [14]. 
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the more structured the knowledge fragments, the simpler their aggregation and 
reuse. 

In fact, approaches like “Learning Objects” [15] postulate that knowledge 
should be represented in small units like atomic content and that all documents 
that can be formed using these should be represented as aggregates that mark 
up the structure and only reference the content. Such aggregates are lightweight, 
ephemeral structures that can be created on the fly and for special situations, 
while the learning objects form the heavyweight base of knowledge, that is ex- 
pensive to create but can be reused in multiple aggregates. 

Basically the same idea was realized with the semantic data format OMDoc 
where a document is considered to consist of a narrative document with links to 
a content base that is another OMDoc document (see [20]). Here, the ‘learning 
object’ is extended to a ‘content object’ by taking the context into consideration, 
enhancing it’s semantic value and making it more reusable in the process. 

2.3 Dissolving the Author’s Dilemma: Creator Support 

In the framework of the (new) content authoring process, we can see that the 
role of a document author, which used to intimately link the activities of content 
creation, content aggregation, and content presentation can be split up into two 
roles: creator and aggregator. The aggregator collects and presents atomic 
content, whereas the creator builds atomic content so that we might use the term 
couteut author as well. In fact, we expect that over time the classic academic 
roles of teacher, survey paper author, or science journalist will be concerned 
mainly with content aggregation, adding only descriptive text to existing content 
objects. Currently, the value of semantic markup shows itself only later in added- 
value services - not at the time of the actual content creation. Not surprisingly, 
the added- value applications have concentrated on the consumers of the semantic 
data and not on its producers. 

If we reformulate the author’s dilemma as a cost-benefit equation in these 
terms, it reads “The creator’s loss is the aggregator’s profit.” In other words, 
the allegedly specific ‘real payoff’ expectation in the author’s dilemma scenario 
really isn’t one for the creator of the semantic data. The obvious conclusion 
consists in separating the single cost-benefit equation into one for the content 
author and one for the aggregating author. The author’s dilemma dissolves if we 
can give the creator his own motivation for creating semantic data. In particular, 
equipping the creator uot ouly with specific couteut authoring support 
but also with added-value services will help solve the MKM authoring 
problem. 

Our approach to promote the creator starts with the concept of an inva- 
sive editor. Generally, authors select document creation systems (editors) with 
a particular purpose in mind - for instance in the face of presentational tasks. 
They frequently opt for editors optimized for the intended output media like 
data projectors (e.g. PowerPoint as presentation editor) or journals (e.g. emacs 
as a DTf<]X-editor) . As these editors optimize their output facilities to the pre- 
sentational task at hand, they usually don’t contain infrastructure for content 
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markup. If an author wishes to annotate his knowledge, then he often has to 
leave his accustomed editor to use other tools, which is perceived as painful 
by experienced users. This is clearly a hurdle for an author’s willingness to do 
semantic markup and can be alleviated by providing semantic editing facilities 
within the chosen editor. We call an editing facility an invasive editor, if it 
is build into an existing application and performs neglected functionalities like 
content markup. Such an add-on is nurtured by the existing editor in the sense 
that it adopts its feel, look, and location. 

The apparent plus for a content author consists in the fact that she can write 
and markup documents in her usual work environment at the same time. But 
the real benefit is the following: she can improve the quality of her document by 
executing content checks and by visualizing the properties (e.g. stringency) of 
its content. In short, an invasive editor provides the potential point of entry for 
creator support and creator- specific added-value services in her chosen editor. 

The concept of an invasive editor is latent in many modern document- or 
program development environments, and in fact a desired phenomenon. ‘Host 
systems’ provide scripting facilities that can be used to create interfaces to other 
dimensions of information in the documents. For instance, the various office 
suites offer some variant of VBA (Visual Basic for Applications), formatting sys- 
tems like HTgX have a built-in macro processor, and computer algebra systems 
have embedded programming facilities. A crucial prerequisite for the suitability 
of a host system consists in the extensibility of the document storage format. We 
do not consider simple extensions like emacs modes for programming languages 
or semantic data formats as invasive editors, since they only provide editing 
facilities for dedicated file formats, and lack the added dimension. 

In the Course Capsules Project (CCaps [8,22]) at Carnegie Mellon Uni- 
versity we have experimented with two invasive editors with complementary 
characteristics: nb2omdoc [25], an editor plug-in for Mathematica as a 
computer-algebra-oriented and therefore mathematically interactive system, and 
the CPoiNT system for MS PowerPoint (PPT) as a purely presentation-oriented 
editor. We will present the latter in the next section. 



3 CPoiNT — An Invasive Editor for Content in PowerPoint 

Before we present the CPoint application let us consider the discrepancy be- 
tween existing knowledge and its presentation in PPT. Based on this analysis, 
we will take a look at CPoint’s forms for semantic data input, its support 
for content authoring, and finally demonstrate the PPT author’s added-value 
utilities implemented by CPoint. 

3.1 Presentation vs. Knowledge 

CPoint’s goal is to provide an author with an interface to explicitly store seman- 
tic information (knowledge) in the PPT slide show itself without destroying the 
presentational aspects of the PPT document. Critical to the task is the apparent 
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gap between the content in a PPT document and the intended communication 
of knowledge in a PPT talk. 



Knowledge is the psychological result of perception 
and learning and reasoning 

http: //www. cogsci .princeton. edu/cgi-bin/webwn 



A Priori Content. MS PowerPoint is a visual editor and player for slides 
in a presentation. Thus, it exclusively addresses presentational issues — the 
placement of text, symbols, and images on the screen, carefully sequenced and 
possibly animated or even embellished by sound. Obviously, the text and the 
pictures carry content, and so does the structural, textual, and presentational 
pattern; we will call it the a priori content. In order to assess the quality 
of a priori content, we list a few typical examples: grouping information in a 
numbered list implies ranking information, the act of grouping text bubbles in 
one slide expresses a correlation, or marking text as title with presentational 
means classifies it accordingly. The superficial and somewhat blurred nature of 
the a priori PPT content is obvious, as a consequence, the knowledge that is 
implicit in a PPT presentation cannot be exploited for added-value services. 




Fig. 1. A Priori Content and Implicit Knowledge in a PPT Presentation 



Implicit Knowledge. The audience in a PPT talk perceives the a priori content 
in the PPT document together with what the lecturer says. This is followed 
by the user’s learning and reasoning process: content becomes knowledge by 
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categorizing the perceived information and combining it with what a user already 
knows. The author on the other hand already has this knowledge and while he 
is creating the PPT document he is using it implicitly. So the ‘real’ content 
is hidden beneath the presentation form and has to be captured and stored to 
make it available to MKM techniques. Figure 1 shows the interplay of a-priori 
content and implicit knowledge. The global context, e.g. the placement of one 
lecture in an entire course, is another part of the implicit knowledge. Following 
OMDoc, CPoiNT captures this via the notion of a collection, encompassing a 
group of inter-related PPT presentations. 

Explicit Knowledge. CPoint provides functionality to make the implicit 
knowledge in a PPT presentation explicit. The PPT content author is sup- 
ported in 

— marking up the ontological role of a PPT object 

— annotating its relation to the local and global context, i.e. to the just-learned, 
about-to-be-learned, and assumed knowledge elements, and 

— adding background knowledge that is presupposed in the course but not 
presented in the slides. 

We will call the resulting, explicitly annotated knowledge PPT content in 
the following. The two-stage annotation process will be described in detail in 
Section 3.2. For the transition from implicit to explicit knowledge see Figure 2. 






Explicit Knowledge 

(cPoffffs \rtsinlize Motte) 



Description 

categoilzedns 

Definition 

“Equivalence Relation" 



Equivalence Relations 



The relation is an equivalence relation 
if (for all a. b. and c) 

a ~ a reflexive 

a ~ b iff b~ a symmetric 

a ~ b & b~ c a~ c transitive 




Example.? 



•Context captured in 
categoy “Example” 

/ ♦ coiifenr lefeieiice 
“Example for 
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property determined 



transitive, reflexive, symmetric 
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1 Ejcajrqi]e3 (text) 
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Fig. 2. Explicit Knowledge in a PPT Presentation 



3.2 The CPoint Application 

CPoint [17] is a PPT add-in that is written in VBA. To store the semantic 
information in the PPT files, it makes use of the fact that PPT objects can 
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Fig. 3. The CPoint Menu Bar 



be persistently ‘tagged’ with arbitrary strings. CPoint is distributed under 
the Gnu Lesser General Public License (LGPL [13]), the newest version can be 
downloaded from http : //cs . emu . edu/~ccaps. 

The CPoint add-in makes its functionality available through a toolbar in the 
PPT menu (see Figure 3) where it is at an author’s disposal whenever the PPT 
editor is running. The top-level structure of a PowerPoint presentation is given 
by slides. Each slide contains PPT objects, e.g. text boxes, shapes, images, or 
tables. By using CPoiNT the author can attach additional information to each 
PPT object so that it becomes a semantic object. 

As CPoint wants to model the implicit knowledge in a PPT presentation 
and aims at facilitating the annotation process, it is geared towards the under- 
standing process. Therefore we will continue with the application’s illustration 
along the process’ characteristics: categorizing and combining. 

Categorizing: The CPoint Categorize Form. The very first step in the 
categorizing process of an object is a naming act (title assignment) which lifts 
its content from e.g. mere text to a knowledge object (see Figure 4). 




Fig. 4. The CPoint Categorize Form 

Classification is neither simple nor unique. First, individual styles vary a lot. 
Secondly, objects like texts or images may be used in different ways: An image 
of a tree in full bloom for instance is used narratively in a lecture about trees in 
computer science whereas a textual definition of a tree in the same lecture clearly 
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contains knowledge. On the other hand the tree’s picture may be definitional in 
a lecture about blossoms in biological science. Furthermore, objects can be pure 
repetitions and even though they might contain content, not all appearances are 
used as content objects. Analogously, a knowledge element might be described 
more than once in a presentation, so that the object and its reformulations are 
equivalent. Therefore CPoint distinguishes an object’s didactic role in a PPT 
presentation to be narrative, content, or that of a repetition or reformulation for 
another object. 

The didactic role restricts the subsequent category selection - available as a 
drop-down menu by a right mouse click - as it is only compatible with a subset 
of pre-defined categories. Categories range from formal mathematical categories 
like “Theory”, “Definition”, or “Assertion” to didactic elements. 

Sometimes, components of what should be categorized as a single knowledge 
element are spread over several slides for presentational reasons, possibly inter- 
rupted by excursions here and there. In such cases, the original assumption that 
(groups of) PPT objects directly correspond to knowledge objects is no longer 
valid. For such situations, CPoint provides sequel objects that tie a compo- 
nent to the respective previous knowledge element part. These are not individ- 
ually categorized, the first in line contains the semantic data for the sequel list. 




Fig. 5. The CPoint Content Form for an Example 

It is not always clear what an object’s content is (e.g. look at ’the’ object 
in Figure 5 and think of it as ungrouped set). In particular, the presentational 
information might contain more (category-independent) knowledge than is ex- 
plicit. Therefore CPoint allows to differentiate an object’s content type to 
influence the conversion process. The value “text” (the default) results in a di- 
rect incorporation of the text value into the external representation. The content 
type “graphics” triggers the creation of a picture of the object itself and/or all 
underlying objects at conversion time. This is useful if only the combination of 
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objects describe a knowledge element like a set of circles with single letters and 
lines between them may illustrate a tree. The content of each object is not note- 
worthy (e.g. a letter), but their placement in the entity is. Finally, the content 
type “code” is a specialization for the original application to Computer Science 
content in the CCaps project. We anticipate that future applications of CPoint 
will extend the repertoire of content types. 

Combining: The CPoint Content Forms. After a PPT object has been 
classified, we must make its relation to the knowledge context explicit via the 
respective detailed content form. 

In Figure 5 we see the content form for a PPT object. Here, a specific tree 
(consisting of nodes and edges) is an example for the concept of a (formal) tree. 
In this case, the example is the PPT object itself (witnessed by the selection 
in the Object field of the form). If the PPT object were e.g. a text box with 
“Example: a directed graph unrolled” this would serve the purpose of an example 
(and thus would have been categorized as “example” in the previous step), but 
the text object itself only serves as description of another object (the directed 
graph) which is the real example and should be referenced in the Object field of 
the form. 



3.3 CPoint’s Support for the Content Author 



The following CPoint services equip the PPT author with 
creator-specific tools for content authoring. Many of them di- 
rectly allow the author to connect her content to a wider 
knowledge context of MKM materials. The CPoint Author 
panel provides a tool palette for displaying and editing cen- 
tral CPoint annotations of the currently selected object. 
While the facilities described in the last section concentrated 
more on the semantic annotation process for pre-existing text 
objects, CPointAuthor focuses on the creation of semantic 
objects in the content authoring process The presentational 
properties of these are preset by the authors personal pref- 
erences, which can be individually configured in a CSS file 
(Cascading Style Sheets [6]) associated with CPointAuthor. 



3Si 




Our Formal Tree 
For ourTree 



aa 






Theory I Definition 



EKample I Exercise 



Assertions I Didactics 



ran 



Visualize Mode. As the semantic markup must not disrupt the presentational 
aspects of a PPT document, CPoint provides a so-called visualize mode at 
design time. By activating it, annotation labels for semantic objects are created 
that contain the category information as well as the title and content type of an 
object. At the same time invisible objects like symbols and abstract objects are 
visualized. An associated hide mode clears the labels. 



The Navigator Button. Generally, the purpose of a content form is to enter 
referential information that elucidates an object’s contribution to and depen- 
dence on the knowledge context. Since such references can be local (inside the 
current slide show), in the current collection, or even in some external knowledge 
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source (e.g. the MBase mathematical knowledge base), finding and specifying 
reference targets is one of the major difficulties of semantic markup in general. 



For each of the scopes, CPoint deter- 
mines the possible target elements (silently 
loading the necessary documents or connect- 
ing to external knowledge sources) and dis- 
plays them in the adjoining selection box. 
Since this will normally be too many for a 
drop-down menu, the user can restrict the 




search space by various filters (e.g. category) available on right-click. In the 



figure on the right we can see the Navigator Button and the list of target objects 



in the Local presentation. 



Navigation. As additional 
navigational help CPoint 
offers the GoTo interface. 

The author may search for 
objects with certain criteria, 
restrict the found set by fil- 
ters, determine in what pre- 
sentation to look for objects, 
and if he selects one object, 
he can go to that object di- 
rectly. On the right we can 
see that the user searched in 
the active PPT presentation 
for all objects which have the word “tree” in their title and are categorized as 
example. The PPT show contains two yielding objects which are collected in 
the selection box on the upper right hand of the form. 




Export to OMDoc. The convert functionality allows a user to convert a 
fully (CPoiNT-)edited PPT presentation into a valid OMDoc document from 
within the PPT editor. Other OMDoc sublanguages are also supported. In par- 
ticular, it can generate a document in presOMDoc, which is common OMDoc 
extended by presentational elements, and AmOMDoc which can be read by the 
ActiveMath application. 

Note, that the conversion utility recognizes T[;]XPoint [24] inlays, the un- 
derlying DT[5]X code is conserved (as code) in the output OMDoc file. 

Import from OMDoc. As a PPT document contains a lot of presentational 
information, CPoint’s import is based on presOMDoc documents. These can 
be imported from within the PPT editor. The presOMDoc file is first read in, 
then a new PPT presentation is generated from these parsed OMDoc elements 
yielding the presentational information present in the document. The generaliza- 
tion to an import feature of OMDoc documents with the usage of an individual 
CSS file is at planning stage. 






186 A. Kohlhase and M. Kohlhase 

Connection to the Outside World. CPoiNT exports files, which then can 
be accessed by the author directly. Furthermore, the documents are opened 
with an editor according to their file type and the user’s personal preferences. 
Therefore, the author could read for instance generated OMDoc files with an 
emacs editor with OMDoc mode. 

Editor Notes. An editor notes module CPointNotes is available. The author 
can create (groups of) notes, searching in one or all groups for his notes and 
jumping from one to another. If an author for instance does want to supply 
background information, but wishes to finish creating the lecture first, he tags a 
missing reference by setting an editor note in the group “background” to remind 
him of inserting the missing references later on. At the same time he finds the 
phrasing of the text still wanting, so he creates another note for this object in 
the notes group “polish” . 

3.4 Added- Value for the Content Author 

In the CPointGraphs module [18] the user is enabled to view the annotated 
structure in a graph format, i.e. the dependency tree of the knowledge elements 
is visualized. It offers several distinctive views from a general survey of theories 
in a collection or presentation to a single detailed theory graph. In Figure 6 we 
get an idea how extensive the knowledge in a course really is. Note for example, 
that nodes without dependencies might be considered superfluous. 




Fig. 6. CPointGraphs: The Theory Graph for a Course 



The CPointAM module contains an integrated development environment 
for ActiveMath content. It allows a user to start and stop the ActiveMath 
application, to check for errors and to set parameters. Furthermore, it includes 
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a utility for converting an entire PPT collection into an ActiveMath course. 
Additionally, it implements an ActiveMath guided tour button in the context 
menu of each object. This button causes ActiveMath to create an individual- 
ized, self-contained document that leads up to the knowledge embodied in this 
object [23]. 

3.5 System Evaluation and Case Study 

The CPoiNT system has co-evolved with a large case study, the course “15- 
211 Fundamental Data Structures and Algorithms”. 15-211 is an undergraduate 
course at Carnegie Mellon University (taught twice annually over a period of 10 
years by a group of 10 faculty members). The current base of course materials 
contains about 2500 PPT slides, of which about half have been annotated in 
CPoiNT, the rest being duplicates, variants or obsoleted versions. Our intuitions 
of the MKM authoring problem and many of CPoint’s auxiliary features have 
been shaped by this case study. Annotation time per slide (for a talented student) 
was about 10 minutes, which leads to a 60% MKM overhead, if we assume an 
average slide creation time of 15 min. 

The case study revealed, that without adding background material (that is 
conveyed orally by the teacher during the lecture) the annotated slide show is too 
thin as the only resource of content for an MKM system like ActiveMath. The 
perhaps most surprising result in the case study was that the mental model the 
authors had of their course materials was changed by the semantic annotation 
process, resulting in more structured slides, more emphasis on prerequisites, and 
less presentational gimmicks. 



4 Conclusion and Future Work 

In this paper, we address one of the central questions for the success of MKM 
techniques “ Why is it so hard to motivate people to annotate their documents 
semantically when they agree at the same time to its usefulness and even to 
its exciting potential?’ . We characterize the underlying problem as an author’s 
dilemma and argue, that the alleged pay-off for semantic annotation is not a 
specific expectation for a content author. This predictably leads to the MKM 
authoring problem. We propose the adoption of invasive editors with creator 
support and creator-specific added-value services to dissolve the content au- 
thor’s dilemma. We present the CPoint system, an invasive, semantic editor in 
Microsoft PowerPoint and illustrate its content author support. We expect that 
invasive editors will lower barrier for authors, help them manage their extensive 
collections of presentations more effectively, even without assuming cooperation 
benefits by sharing materials. 

However, the surprising result of research on the prisoner’s dilemma is that 
cooperation spontaneously emerges even in such a hostile situation, if the exper- 
iment is iterated and a subset of players experiment with altruism (see [5] for 
details). Qualitatively, it is safe to say that cooperation emerges earlier, converges 




188 



A. Kohlhase and M. Kohlhase 



sooner, and tolerates more freeloaders, if the cooperation benefit is strengthened 
and the cost of unreturned cooperation is mitigated. This suggests that invasive 
editors will also play a role in fostering cooperation. 

In the future, we envision a new PPT add-in module CPointPresenter 
supplementing the existing module CPointAuthor for the different roles a 
user can play. A presentation author (a presenter) will be supported during the 
composition of a presentation. He will search, find, and build new presentations 
based on existing knowledge elements. Here, we want to stress and facilitate 
the aggregator function of e.g. a lecturer. For a content author we can conceive 
further support by the application of information retrieval techniques to suggest 
categories and references for content objects. This will be particularly helpful for 
the migration of legacy materials to semantically enhanced formats like OMDoc. 
As knowledge is present in other document formats as well (probably even more 
so), another goal is the implementation of a CPoiNT clone in MS Word. Finally, 
we plan to connect CPoint to the MBase system [21], so that all knowledge 
captured in OMDoc documents and stored in an MBase can get directly used. 
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Abstract. The more extensive use of diagrammatic representations as 
a tool for managing complexity and communication problems of mathe- 
matical knowledge is advocated in the paper. The specifics of this 
representation tool are introduced, including the problems with using 
diagrams in mathematics, issues of proper design of diagrams, specifi- 
cation of main usage types of mathematical diagrams and ways of their 
implementation. The discussion is illustrated by a number of diagrams, 
mostly taken from the diagrammatic notation for interval algebra re- 
cently developed by the author. These and other issues of diagrammatic 
representation and reasoning are investigated by the recently emerging 
discipline of diagrammatics. 



1 Introduction 

When thinking about managing some area of knowledge, one should realize first 
who and in which way will use it, as the form in which the knowledge should be 
represented and managed crucially depends on the kind of its usage. Concerning 
the mathematical knowledge, there are two main classes of users of it: 

— Mathematicians, especially working in the same area of mathematics, and 

— Users of mathematics, coming from other branches of science and technology. 

The second class of users of mathematical knowledge repositories seems to be 
much more numerous, and they will most benefit from computerization of the 
repositories. 

Unfortunately, most of the current projects of computerizing mathematical 
knowledge bases are seemingly constructed by mathematicians for mathemati- 
cians only. They use the impenetrable (for non-mathematicians) theorem-proof 
organization of the knowledge, are based on logical representations only, and in 
most cases use the somewhat old-fashioned human-computer interface paradigm 
of a one-dimensional string of ASCII characters, ignoring the capabilities of cur- 
rent computer systems in setting mathematical formulae and drawing diagrams 
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and other visualizations. That may be acceptable for mathematicians (though 
one can doubt if all of them would be happy when forced to abandon their fa- 
miliar mathematical notation for the illegible ASCII coding), but it is rather not 
acceptable for users of mathematics. 

Users of mathematics have quite different needs in this respect than work- 
ing mathematicians. To make the knowledge accessible to them, and managing 
complexity and intricacy of mathematical knowledge, one must use much more 
efficient knowledge representation methods, both in the sense of efficiency of 
encoding and storing the knowledge and efficiency of reading and absorbing the 
knowledge by the user. One of such efficient methods of representation of complex 
information is provided by diagrams. They offer readable general comprehension 
of some part of knowledge “at a glance,” allowing also for representation of pre- 
cise structural relationships. However, unfortunate expulsion of diagrams from 
most of mathematics arrested the development of proper design and use of good 
and informative mathematical diagrams. The situation changes recently - the 
field of diagrammatics, analogical to the field of linguistics devoted to the study 
of language representations, finally emerged. Using findings of research in this 
area (see e.g. [4, 5, 18] and article collections and proceedings like [1, 2, 7, 12]) it 
becomes possible to use diagrammatic representations in an efficient and reliable 
way to represent and manage complicated mathematical knowledge. 

An example of a system trying to go in this direction is the Theorema Project 
(see http://www.theorema.org/) for computerized theorem proving. With it, it is 
possible to annotate proof steps graphically, using a system of so-called logico- 
graphic symbols [8]. On the other hand, tools like Maple or Mathematica, though 
containing a significant graphical component, do not provide a sufficient integra- 
tion of these graphics tools with the mathematical base (except possibly with 
some rudimentary tools for graphing of functions), leaving the construction of the 
link between mathematics and diagrams almost entirely to the user, by means 
of low-level programming from basic graphical primitives in a way often much 
more troublesome than with common interactive graphic editors. 

The paper starts with an explanation of what is understood by a diagram here 
and what are the main properties of this kind of representation. Then follows a 
summary of the use of diagrams in mathematics, especially a critical discussion 
of main arguments against their use here. This is followed by a discussion of main 
issues concerning the criteria for designing good diagrams, and the description 
of main types of use of diagrams in representation of mathematical knowledge, 
with diagrammatic examples mostly taken from the recently developed diagram- 
matic notation for interval algebra [18]. Finally, a short discussion of possible 
ways of implementing and using diagrammatic tools in mathematical knowledge 
bases is included. The paper is concerned mostly with diagrammatic represen- 
tation of mathematical knowledge. The issue of using diagrams for reasoning 
(e.g., proving theorems) is only superficially touched upon. Note, however, that 
diagrammatic reasoning is closely related to diagrammatic representation - one 
must first represent the mathematical knowledge involved in order to be able to 
reason with it. See [4, 5, 13, 18, 27] for more on this issue. 
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The paper is based in significant part on discussions included in [18], with a 
number of modifications and additions. However, Sections 5 and 6 are entirely 
new, with an exception of a number of example diagrams taken mostly from [18] 
(though some of them are also substantially modified) . 



2 What Are Diagrams? 

There is still no fully agreed consensus among researchers in diagrammatics as 
to the precise definition of a diagram (see e.g. [25]). Generally, a diagram is a 
kind of an analogical representation of knowledge, as opposed to more familiar 
propositional representations. 

Consider an example of analogical representation, like a geographical map. In 
the map, size of, direction to, and distance between marks directly represent size 
of, direction to, and distance between real objects on the ground, say cities. In 
contrast, in a sentential (propositional) representation, like in the phrase “The 
city 250 km south of Warsaw”, its parts (e.g., the word “Warsaw”) or relation- 
ships between them (e.g., that “Warsaw” appears after “south” in the phrase) 
need not correspond to any parts and relations within the thing denoted. The 
same is true for a more formal propositional representation, like predicate cal- 
culus formulae. Thus, an analogical representation has a structure whose syntax 
parallels (models), to a significant extent, the semantics of the problem domain, 
while a propositional representation has a structure that has no direct bearing on 
the semantics of the problem domain. Diagrammatic representation can be thus 
defined broadly as an analogical representation presented by visual means, of 
some (not necessarily visual) data or knowledge. There are other, more involved 
definitions of the term. One definition of interest says that diagrammatic rep- 
resentation is a plane structure in which representing tokens are objects whose 
mutual spatial and graphical relations are directly interpreted as relations in the 
target structure. 

It is important to bear in mind that the propositional versus analogical dis- 
tinction is neither absolute nor sharp. There are various degrees of analogicity 
(see e.g. the discussion of verbal versus visual thinking in [3]), or the representa- 
tion may be analogical along certain dimensions (or aspects), but propositional 
along others. The limiting case is reasoning directly with (or simulating) the 
target domain itself: if you cannot infer which lid fits the jar from the avail- 
able information, try them on in turn. At the other extreme one can place, e.g., 
a Morse code, where the syntactic structure of dots and dashes bears little if 
any discernible relationship to the structure of whatever the message is about 
(examples taken from [6]). 

The representation may thus contain elements of both kinds discussed, be- 
coming thus a hybrid representation (called also heterogeneous [6] or multi- 
modal) . This situation is ubiquitous in practice - it is very hard, if not impossible, 
to find examples of indisputably pure cases. In particular, in mathematical di- 
agrams the propositional components are often essential, or even indispensable. 
They should co-exist with the diagrammatic ones, so that both complement each 
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other, with the diagram providing a general look of the structure of the prob- 
lem and formulae adding precision in important details or specifying limits of 
generalization of the argument, see Section 5. 

Diagrammatic representations should not be confused with the term geomet- 
rical interpretation (which should be rather called “geometrical representation” 
anyway). The term means representing some non-geometrical knowledge in terms 
and notions of geometry. That may, but does not have to, involve diagrams. Note 
also that diagrams, even geometrical diagrams, can (and quite often do) contain 
visual language elements that are not geometrical (i.e., that do not represent 
any geometrical objects or notions), like arrowheads, various thickness or dot 
patterns of lines, colour, shading or cross-hatching of areas, etc. 

3 Diagrams in Mathematics 

The use of diagrams in mathematics has a long and respectable history, in the 
course of which various attitudes towards that use were maintained. Attitudes 
towards diagrams in other branches of science were usually more stable, but 
although they were used there extensively and without much reservations (espe- 
cially in engineering and other technical disciplines), they were rarely treated as 
important components of scientific practice in these fields, important enough to 
deserve a rigorous study, not to mention a separate branch of science. 

The most naturally diagrammatic field of mathematics is obviously geometry, 
so it is not surprising that “The Elements” by Euclid, the first mathematical text 
on geometry foreshadowing the modern axiomatic approach to mathematics, re- 
lied heavily on diagrams. Diagrams were later applied not only in geometry. A 
simple diagram of a number axis played an instrumental role in eventual accep- 
tance of negative numbers as a respectable mathematical entity, for a long time 
before that called numeri ficti (fictitious numbers). A similar story repeated it- 
self with the invention of complex plane diagram (or Argand diagram) which not 
only stimulated the acceptance of “imaginary numbers,” but played a significant 
role in the development of complex analysis, see [23]. In this role, the complex 
plane diagram has not yet said its last word, as it is shown by recent invention 
of diagrammatic representations for some operations on complex numbers, until 
now thought to be not representable in this way [23] . 

However, with the invention of predicate calculus by Frege and the birth of 
Hilbert’s program of formalization of mathematics at the end of the XIXth cen- 
tury, diagrams went out of fashion as a respectable research tool in mathematics 
and their use is considered a bad practice and actively discouraged till now. 
The trend went so far that some mathematicians (like Dieudonne, a member 
of the Bourbaki team) wrote books on geometry without a single diagram and 
were proud of that. The fashion persisted despite the fact that many promi- 
nent mathematicians admitted the use of visual images and diagrammatic aids 
in their mathematical research [10]. Diagrams were accepted at most as a sec- 
ondary illustration device, suitable as an educational tool for uninitiated. As a 
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result, the research on proper design and use of diagrams stalled, leading to easy 
accusations that diagrams are difficult and unreliable to use. 

When proposing diagrams as a significant element of mathematical knowledge 
representation it is fair to consider the arguments against their use in mathe- 
matics. They can be listed under three main headings: difficulty^ unreliability, 
and informality (of diagrams). Let us examine them in turn. 

Difficulty. Even some prominent users and advocates of diagrammatic methods 
expressed opinions about the difficulty of using them, like Feynman [9] or Need- 
ham [23] . But while for some people it may be quite difficult to think pictorially, 
for others this can be actually an easier mode of thinking than the propositional 
one. In this respect the human population is divided roughly in half ~ one half 
being more proficient in verbal, and the other half in visual thinking. However, 
with the educational bias toward verbal learning and discouraging the use of 
diagrams, visual thinkers have rough times in school and after it, so that their 
visual abilities are seldom properly trained and used to their full potential. This 
applies especially to people seeking a career in sciences. Not surprisingly, the 
proportion of people for whom diagrammatic thinking is easy seems to be much 
smaller among scientists than in the overall population. 

Besides perceiving and imagining diagrams, an effective use of them requires 
an actual drawing of (often many, and intricate) diagrams. With the equipment 
provided by human biology it is indeed difficult to produce diagrams of any com- 
plexity and accuracy - humans do not have a proper and effective visual effector, 
comparable in efficiency to that one we use for spoken language. Fortunately, 
in our times we do have technical means (namely, computers) very efficient in 
producing complex pictures. We can use them as a sort of prosthetic devices 
compensating for our deficiencies in this area. 

Unreliability. It is true that, as observed by Arnheim [3]: “Perception ... is 
unreliable, as shown by the many optical illusions, and can refer only to actual, 
physically given objects, which are always imperfect.” It is thus not surprising 
that representation of knowledge in diagrams and reasoning conducted with them 
are prone to various errors. This is a significant problem impeding practical use 
of diagrams in rigorous reasoning. This, however, applies in a significant degree 
to all other representations and reasoning tools. The differences here boil down 
to different causes and types of error situations and different ways to avoid them. 

Moreover, as observed in [6], “If we threw out every form of reasoning that 
could be misapplied by a careless reasoner, we would have little if anything 
left.” Thus, we must learn to live with possibly error-prone representations. For- 
tunately, most of these errors can be avoided by careful design and use of the 
appropriate visual language well adapted to the given task, augmented by the 
knowledge of possible error situations and methods of avoiding them. Once these 
situations are properly recognized, analyzed in detail, and taught to the users 
of diagrams, the possibility of errors in diagrams can be made no more harmful 
that in any other human activity. Unfortunately, the proper error-avoidance rules 
for diagrams are not yet fully investigated, codified and taught. This problem 
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constitutes the important challenge for the researchers in the field of diagram- 
matics. Some preliminary analysis of the topic appeared in [17,18]. From the 
list of possible error causes discussed there it is worth to mention the problems 
of diagram imprecision and particularity. Diagram imprecision (see the quote 
from Arnheim [3] above) may lead to various kinds of errors, like generation of 
impossible cases [17]. Particularity of diagrams (interpreted often as a lack of 
variables in diagrams) leads to problems with representing the proper range of 
generalization of the argument from the particular case provided in the diagram. 
There are various remedies for this effect, e.g., the configuration transformation 
diagrams discussed in Section 5. 

Informality. This argument says that, by their nature, diagrams cannot be made 
formal enough to be acceptable as valid components of rigorous mathematical 
proofs. Actually, it is already disproved by many fully formalized systems of 
diagrammatic reasoning that have been developed, see e.g. [11, 13, 22]. However, 
the question has some interesting aspects worth considering in more detail. 

This objection against mathematical diagrams was raised by the Hilbert’s 
programme of formalization of mathematics. In writings of Pasch and Hilbert 
himself, their position on that issue is clearly stated, see the quotes discussed in 
[18]. The argument in these quotes says, in effect, that the formal mathematical 
reasoning must be restricted to mechanical manipulation of symbols, without ref- 
erence to any “sense” of the underlying mathematical concepts, while diagrams, 
allegedly, constitute the direct embodiment of just these concepts. 

Do diagrams really contain directly “the sense of geometrical concepts”? As 
diagrams are analogical representations, it seems reasonable to assert that. How- 
ever, in practice we never attain full analogicity: a line in a diagram is not a line 
as understood in geometry - it is only a (often crude and approximate) repre- 
sentation of the appropriate geometrical concept. It then has the similar status 
as a symbol used in a propositional proof, containing no diagrams. From this 
point of view, diagrams can be considered as a different symbolic notation, useful 
to represent geometrical entities in the same way as certain other squiggles on 
paper are useful as representations of numbers, logical or arithmetic operations, 
and the like. Moreover, diagrams are also finite arrangements of symbols from a 
finite alphabet. One cannot draw an infinite line with infinite precision no more 
than one is able to write in a formula an infinitely precise letter “x” exactly 
identical in shape to the previous one. Thus, diagrams can also be constructed, 
transformed and inspected in a finitistic way, just like the formulae. 

It is of course true that directness {analogicity) of diagrams, so that they 
seem for a human reasoner to more vividly represent the underlying mathemat- 
ical concepts, their important features, and relations between them, does in a 
way introduce into the reasoning process the semantic reference to the concepts 
concerned. But that actually helps to creatively conduct rigorous reasoning, pro- 
vided of course that one observes necessary precautions against misuse of the 
notation, as one must do also when using formulae. 

Consider also that no mathematician actually works by a purely mechani- 
cal juggling of meaningless symbols. Practically, nobody even works with the 
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pure logical notation of the predicate calculus. That would greatly impede the 
efficiency of mathematical work. Instead, mathematicians use, and constantly 
expand, quite intricate symbolic notation systems, containing also lots of es- 
sentially diagrammatic elements like two dimensional fractions, subscript and 
superscript systems, matrices, morphism diagrams, often very pictorial operator 
or relation symbols, and the like. They also to some extent use the so-called 
model-based reasoning, utilizing various semantic cues to navigate through the 
space of formal descriptions of the steps of the reasoning. The importance of 
such guidance in mathematical reasoning was well attested by Hadamard [10]. 

4 Designing Good Diagrams 

Every representation of complex knowledge, to be sufficiently expressive, effi- 
cient, and useful, must be well designed. This obviously concerns diagrams too. 
Good design here must be considered on several levels. 

The syntactic level concerns such requirements as sufficiently rich visual vo- 
cabulary, proper use of visual relations (to fit properties of target domain re- 
lations), and precise drawing. Mathematical diagrams historically used rather 
primitive visual vocabularies, which did not allow for adequate expressiveness 
and rich information content. A typical example of a common “textbook style” 
diagram is shown in Fig. 1(a) (adapted from [3]). Such diagrams must be accom- 
panied by extensive textual explanations as shown, and thus they serve merely 
as additional illustration of the contents in most part communicated proposition- 
ally. Graphical medium, however, allows for much more rich visual languages, 
as illustrated in Fig. 1(b). For those familiar with the visual language used, the 
diagram can be self-explanatory; anyway, much simpler explanations suffice, and 
they can be made a part of the diagram itself, producing a truly hybrid repre- 
sentations, like in Fig. 1(c) and in diagram examples in the rest of the paper (see 
also [18]). In this respect, the term “proofs without words,” often associated with 
the use of diagrams in mathematics (see [24]), is misleading. It suggests a wrong 
paradigm for diagrammatic reasoning - namely, that we should struggle to make 
purely diagrammatic proofs or representations, without the use of propositional 
ingredients. The proper paradigm relies instead on hybrid representations. Dia- 
grammatic proofs are not distinguished by a lack of words (or formulae) , but by 
the essential role a diagram plays in the reasoning. 

Precise drawing is also very important - like illegible writing, sloppy drawing 
may lead to errors in representation and reading the data off an illegible repre- 
sentation. This concerns equally the overall composition and structuring of the 
diagram, the proper choice of visual primitives, and precise execution of details. 
Despite its obviousness, sloppy drawing is a very common feature of many dia- 
grams. This is probably due mostly to the lack of training in proper design and 
construction of diagrams. Also, as diagrams are often considered to be of only 
secondary importance, especially in mathematical texts, little attention is paid 
to their careful design and execution. 
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In order to prove that the triangle AABC based on the diameter AB of the 
circle is always right-angled (i.e., ZACB = 90°), draw a line from the vertex C 
of the triangle through the centre O of the circle to the point C' on the circle, 
and arrive thereby at a rectangle ACBC', located symmetrically within the 
circle. By its position in this rectangle, the angle ZACB at the vertex C of the 
triangle is an angle of 90°. 




Fig. 1. Three main styles of mathematical diagrams: textbook style with textual expla- 
nation (a), purely diagrammatic style (b) and hybrid style (c) 

The semantic level concerns generally the requirement of expressiveness of 
the representation, i.e., the possibility to express without error or confusion a 
sufficiently large body of data we want to represent. It may need some effort to 
circumvent the limitations of the Euclidean plane, and asks for the proper use of 
the effects of emergence and divergence (see [18] for discussion of these issues). 

The pragmatic level of diagrammatic languages concerns first their effective- 
ness, i.e., the requirement to minimise costs of both production and using the 
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representation, and making it less error-prone (the latter requirement is very 
important in such rigorous domains as mathematics). Also, the important re- 
quirement is to take into account the function, or supposed usage type, of the 
representation. The main usage types of mathematical diagrams are illustrated 
in the next section. 

As the research on design of mathematical diagrams is still seriously under- 
developed, little more can be added to that listing of general issues to consider. 
The guidelines developed by graphic design community are seldom directly ap- 
plicable to mathematical diagrams (except possibly in the area of graphing of 
functions, see e.g. [26], but even there the specificity of mathematical diagrams 
is mostly not taken into account). The next section presents thus other kinds of 
diagrams than graphs of functions, to illustrate other possible design problems 
and a sort of “guidelines-by-example.” 

In order to be able to produce good diagrams for a particular proof or prob- 
lem, it is very advisable to develop first a comprehensive system of diagram- 
matic representations of objects, notions and relations in a given domain. Such 
a system, with its sufficiently rich visual language, provides ready-made tools 
and building blocks for producing unambiguous and uniformly interpretable di- 
agrams for any particular problem within the domain. One of historical examples 
of such a system, of great significance to the development of its domain, is the 
diagrammatic notation for complex numbers plane [23]. A current example of 
a similar system, this time for interval algebra, constitutes the main subject of 
this author’s research [14,15,16,18,19]. A discussion of some information de- 
sign problems and solutions involved in the development of this notation can be 
found in [20]. The more extensive use of such diagrammatic notational systems 
can substantially help in managing complex mathematical knowledge. 



5 Diagram Usage Types 

Diagram usage types are defined mostly by the main goal they serve. In this 
short and preliminary proposal, four basic types will be discerned and illustrated 
by diagrammatic examples. In practice there are many intermediate cases, and 
diagrams that exhibit elements or features of several types, as commented upon 
in explanations of the examples below. 

Object Structure. This diagram type serves the goal of showing “at a glance” 
how some mathematical object is constructed from its elements, what re- 
lations bind the structural elements and what properties such a structure 
should thus possess. 

Construction Steps. Here the diagram shows the sequence of construction 
steps necessary to build some mathematical object. This may sometimes 
serve also as a structural description of the resulting object, see above. 
Catalogue of Cases. The goal here is to catalogue a number of similar objects, 
types of objects, or reasoning cases. The main emphasis is put on comparing 
the objects and delineate the differences and similarities between them. 
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Sequence of Transformations. This is a sort of dynamic diagram, showing 
a set of transformations of the given mathematical object necessary to con- 
struct another object or to conduct some reasoning. 

The exposition will be illustrated mostly by diagrams from the diagrammatic 
notation developed by the author [14, 15, 16, 18, 19] for interval algebra. Mathe- 
matical background had to be omitted due to the lack of space. The examples 
are not aimed to communicate the details of mathematics of intervals, but to 
show the function and look of the discussed types of diagrams. 

Object Structure. Two examples of mathematical object structures are shown 
in Fig. 2. The set of solution types [16, 18] will be further explained below. 
The second example shows, in the midpoint-radius coordinates, how the set of 
intervals contained in the given interval v (denoted by the gray triangle with the 
apex V and the base between the interval endpoints v and v) is transformed by 
multiplying these intervals by the interval u using the ci-multiplication formula 
studied in [19]. The result of the mapping is the grayed heptagon above the 
bend axis Ou — . . . Ou -|-. Darker gray denotes its intersection with the original 
triangle, and the two dark triangles to the right emphasize a part of the mapping 
of special interest to the mathematical argument conducted with the help of this 
diagram in [19]. This category of diagrams includes as a subtype various popular 
kinds of graphs of functions. 

Construction Steps. Diagrams of this kind show how to build step by step some 
mathematical object, or a result of some mathematical operation. This is done 
usually in a sequence of steps which can be indicated with various diagrammatic 
means, like numbered step indicators (see Fig. 3) or sequences of “animation 
frames,” or alternatively non-diagrammatically in the accompanying textual ex- 
planation. Showing construction steps often reveals also some aspects of the inner 
structure of the object constructed, thus serving in part as the object structure 
diagram discussed above. 




Fig. 2. Graph of solution types of the simple interval equation a-x = b (a) and structure 
of the mapping defined by ci-multiplication in the MR-diagram of interval space (b) 
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Oa+ 




b) 

m ■ u — m ■ mid u±m ■ rad u, 
for m G R'*' . 

u-v = \J{u-v\uGu&z,vGv} = 
= \J{u ■ v\v G v} = 

= \J{u- v,u-v} = 

= (u • w) V (u • v). 



Fig. 3. Construction for a product u • u of two positive intervals (a), compared with 
the formulae on which it is based (b); “V” is the join operation of the interval lattice 



Catalogue of Cases. This is one of the most useful roles played by diagrams, espe- 
cially when we want to gather and communicate systematically some organized 
segment of knowledge. A simple example in Fig. 4 (adapted from a diagram 
in [24], substantially modified) lists various types of mean formulae. It shows 
not only the catalogue of different formulae, but also the relationships between 
means, so that it plays also, to some extent, a role of a structural diagram for 
the space of definitions of means. This is a common (and desirable) feature of 
such kind of diagrams. 

A more elaborate example is given by the simplified catalogue of structural 
types of the interval equation a ■ x = b (Fig. 5, with an explanation of the 
quotient sequence and quotient diagram notation in the inset). The more detailed 
catalogue can be found in [16, 18]. It lists additionally the exact conditions (in 
propositional form) for each type. It is an essentially hybrid representation; in the 
detailed version the propositional contents is even larger than the diagrammatic 
one. 




Fig. 4. Mean formulae and relationships between means: harmonic, geometric, arith- 
metic, and root mean square 
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Configuration Transformations. Here the diagram explains how it should be 
transformed, for the purpose of defining the proper range of cases for some 
diagrammatic argument, or a solution to a problem. In Fig. 6 it is shown how a 
change of position of the coefficient a of the equation a- x = b along a trajectory 
through the interval space changes the structure of its solution sets (defined by 
quotient sequences, see Fig. 5). 

There is an essential difference between this kind of diagrams and the “con- 
struction steps” diagram. The latter one shows the construction of an object by 
adding consecutive components, while the transformation diagram shows how 
the whole diagram, or some its properties, change with the change of some pa- 
rameter or variable. In this way variables can be introduced into diagrammatic 
representations, so that such diagrams can be used to solve the particularity 
problem, see Section 3. They do that by showing the allowed transformations 
of the exemplary object xq to obtain any other object x from the required class 




ab: — h H — ++ 




X K K 

a- b- b+ a+ 



S^f S^L Z^f Z^L 

N: 



N M H N 




°ZLTS TSZL° °STLZ oZTLS TZSL° LSZT° °SLTZ 

i_i i_i i_i i_i 




Fig. 5. A simplified catalogue of types and subtypes of the interval equation a - x = b, 
with explanation of quotients, quotient diagrams, and quotient sequences (inset). The 
small circle “o” marks the position of zero 
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Fig. 6. Movement of the equation coefficient a in the MR-diagram (a) with correspond- 
ing change of types (b) of solution sets structure (c) 




Fig. 7 . A diagrammatic proof of the sum of angles in a triangle, using configuration 
transformation 



X, see [18,21,27]. A simple example (adapted from [3]) is shown in Fig. 7 - 
rotating two sides of the triangle as indicated, one can transform the triangle 
to any shape without changing the reasoning leading to the thesis (assuming its 
invariance with respect to size and rotation of the triangle is obvious). 



6 Implementing Mathematical Diagrams 

In practical implementation of computerized repositories of mathematical knowl- 
edge, diagrams can be included in various ways. The lack of space precludes 
detailed discussion of the issue here, hence only general listing of a few possible 
approaches will be proposed. 

Interactive editors for constructing mathematical diagrams by the user. They 
should be designed to incorporate specific needs of mathematical diagrams, in 
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particular should contain specialized libraries of high-level building blocks and 
editing tools adapted to different diagrammatic notations, as mentioned at the 
end of Section 4. 

Semi-automatic diagram generation from underlying representation, like with 
the existing tools (though often of low quality) for graphing functions. They 
should have a rarely currently available feature of interactive editing by the user 
of the generated diagram. The tools like the logicographic symbols of [8] also 
belong here. 

Libraries of reference diagrams representing various pieces of mathematical 
knowledge (see e.g. the “object structure” and “catalogue of cases” diagrams 
from the preceding section). They can be, where useful, interactively animated, 
like some diagrams at the http://www.cut-the-knot.com/geometry.html site. 

Interactive “diagrammatic spreadsheets” of the sort proposed in [18,21]. The 
diagram, constructed by the user or provided from the reference library, is de- 
fined there as a set of graphical elements linked with appropriate constraints 
assuring its structural integrity during interactive transformations of the sort 
shown in Fig. 7. The main use of such diagrams is for interactive exploration of 
possible configurations of mathematical objects modelled, and in diagrammatic 
reasoning, especially in the cases suffering from the particularity problem. 



7 Conclusions 

To manage complex knowledge, e.g. mathematical, efficient representation tools 
are needed. Diagrams constitute one of such tools, as yet mostly neglected by 
mathematicians. Thus, the ability of diagrams to efficiently represent complex 
mathematical knowledge of various sorts exemplified in Section 5 should at- 
tract more attention of designers of computerized repositories of mathematical 
knowledge. A long-range research and implementation programme in this area 
is much needed. It should address such issues as codification of existing and de- 
velopment of new diagrammatic notations for various branches of mathematics, 
development of design guidelines for good mathematical diagrams, analysis of 
causes of, and proposing remedies for, errors in diagrammatic representations, 
and devising, implementing, and experimenting with new computer tools for 
effective mathematical diagrams generation and use. 
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Abstract. We extend first-order logic with sequence variables and se- 
quence functions. We describe syntax, semantics and inference system 
for the extension, dehne an inductive theory with sequence variables and 
formulate induction rules. The calculus forms a basis for the top-down 
systematic theory exploration paradigm. 



1 Introduction 

The goal of future mathematical knowledge management is the availability of 
significant parts of mathematical knowledge in computer-processable, verified, 
well-structured and semantically unambiguous form over the web and the pos- 
sibility to easily expand, modify, and re-structure this knowledge according to 
specifications defined by the user. For this, mathematical knowledge has to be 
formulated in the frame of formal logics. Translation between presentations of 
mathematical knowledge with respect to different logics should be automatic. A 
natural standard for such logics is (any version of) predicate logic. 

We believe that the goal can only be achieved by a systematic build-up of 
mathematics from scratch using systematic, flexible, algorithmic tools based on 
algorithmic formal logic (automated reasoning). By these tools, most of the work 
involved in building up well-structured and reusable mathematical knowledge 
should be automated or, at least, computer-assisted. We call the research field 
that enables this type of generation of large pieces of coherent mathematical 
knowledge “Computer-Supported Mathematical Theory Exploration” . 

The systems and projects like ALF [26], Automath [13], COQ [2], Elf 
[29], HOL [17], IMPS [1], Isabelle [28], Lego [25], Nuprl [12], Omega [4], 
Mizar [3] , and the others have been designed and used to formalize mathemat- 
ical knowledge. Theorema^ is one of such projects, which aims at construct- 
ing tools for computer-supported mathematical theory exploration. Since then, 
within the Theorem A project, various approaches to bottom-up and top-down 
computer-supported mathematical theory exploration have been proposed and 
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pursued with an emphasis on top-down methods. These approaches and first re- 
sults are documented in various publications and reports (see, e.g., [8, 30, 9, 10]). 
The approaches are summarized in the “lazy thinking paradigm” for mathemat- 
ical theory exploration introduced by the second author in [9]. 

In general, mathematical theory exploration requires higher-order logic. The 
version of predicate logic used in the case studies on theory exploration [30, 9, 10] 
is a higher-order predicate logic with sequence variables and sequence functions. 
However, the proofs in the case studies are done essentially on the first-order 
level. In this paper we restrict ourselves to the first-order fragment of predicate 
logic with sequence variables and sequence functions. 

Sequence variables can be instantiated with finite sequences of terms. They 
add expressiveness and elegance to the language and have been used in var- 
ious knowledge representation systems like KIF [15] or Common Logic [18]. 
Isabelle [28] implements sequent calculi using sequence variables. In program- 
ming, the language of Mathematica [31] successfully uses pattern matching 
that supports sequence variables and flexible arity function symbols (see [7] for 
more details). Sequence functions can be interpreted as multi-valued functions 
and have been used (under different names) in reasoning or programming sys- 
tems, like, e.g., in Set-Var [5] or RelFun [6]. 

The following example shows how the property of a function being “orderless” 
can be easily defined using sequence variables: f(x,x,y,y,z) = f(x,y,y,x,z) 
specifies that the order of arguments in terms with the head / and any num- 
ber of arguments does not matter. The letters with the overbar are sequence 
variables. Without them, we would need a permutation to express the same 
property. Definition of concatenation (x) x (y) = {x,y) is another example of 
expressiveness sequence variables. 

Using sequence variables in programming helps to write elegant and short 
code, like, for instance, implementing bubble sort in a rule-based manner: 

sort((x,x,y,y,z)) := sort((x, y,y,x,z)) if x > y 
sort((x)) := (x) 

Bringing sequence functions in the language naturally allows Skolemization 
over sequence variables: Let x, y be individual variables, a; be a sequence variable, 
and p be a flexible arity predicate symbol. Then VxVyda: p{x, y, x) Skolemizes to 
VxVt/ p{x, y, f{x, y)), where / is a binary Skolem sequence function symbol. An- 
other example, \/y3x p{y,x), where y is a sequence variable, after Skolemization 
introduces a flexible arity sequence function symbol g\ Vy p{y,g{y)). 

Although sequence variables and sequence functions appear in various appli- 
cations, so far, to our knowledge, there was no formal treatment of full predicate 
logic with these constructs. (Few exceptions are [19], that considers logic with 
sequence variables without sequence functions, and [21], investigating equational 
theories, again with sequence variables, but without sequence functions.) In this 
paper we fill this gap, describing syntax, semantics and inference system for 
an extension of classical first-order logic with sequence variables and sequence 
functions. Although, in general, the extension is not very complicated, there are 
some subtle points that have to be treated carefully. 
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In the extended language we allow both individual and sequence variables/fu- 
nction symbols, where the function symbols can have fixed or fiexible arity. We 
have also predicates of fixed or fiexible arity, and can quantify over individual 
and sequence variables. It gives a simple and elegant language, which can be 
encoded as a special order-sorted first-order theory (see [24]). 

A natural intuition behind sequence terms is that they represent finite se- 
quences of individual terms. We formalize this intuition using induction, and 
introduce several versions of induction rules. Inductive theories with sequence 
variables have some interesting properties that one normally can not observe in 
their standard counterparts: For instance, Herbrand universe is not an inductive 
domain, induction rules can be defined without using constructors. 

The calculus G~ that we introduce in this paper generalizes LK~ calculus 
(LK“ is an extension of Gentzen’s LK calculus [16] with equality), and possesses 
many nice proof-theoretic properties, including the extended version of Gddel’s 
completeness theorem. Also, the counterparts of Lowenheim-Skolem, Gompact- 
ness. Model Existence theorems and Gonsistency lemma hold. G“ together with 
induction and cut rules forms the logical basis of the top-down theory exploration 
procedure [9]. 

The main results of this paper are the following: First, we give the first de- 
tailed description of predicate logic with sequence variables and sequence func- 
tions, clarifying the intuitive meaning and formal semantics of sequence variables 
that some researchers considered to be insufficiently explored (see, e.g. [11]). 
Second, we describe the logical foundations of the “theory exploration with lazy 
thinking” paradigm. 

The contributions of the first author are defining syntax and semantics of 
languages with sequence variables and sequence functions, designing and prov- 
ing the properties of the calculus G“, and showing relations between induction 
rules and intended models. The second author pointed out the importance of 
using sequence variables in symbolic computation (see [7]), introduced sequence 
variables and sequence functions in the Theorema system, defined various infer- 
ence rules for them (including induction), and designed provers that use sequence 
variables. 

We omit the details of proofs which can be found in the technical report [24] . 

2 Syntax 

We consider an alphabet consisting of the following pairwise disjoint sets of 
symbols: individual variables Vind, sequence variables Vseq, fixed arity individual 
function symbols fiexible arity individual function symbols fixed 

arity sequence function symbols fiexible arity sequence function symbols 

•^Seq ’^5 fixed arity predicate symbols and fiexible arity predicate symbols 

■pFiex^ Each set of variables is countable. Each set of function and predicate 
symbols is finite or countable. The binary equality predicate symbol « is in 
Besides, there are connectives V, A, =J>, <tA, quantifiers 3, V, parentheses 
‘(’, ‘)’ and comma in the alphabet. 
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We will use the following denotations: V := VindU Vseq; l^ind := -^in’d ^-^ind’^j 

-77 -irFix I I -rFlex. -irFix -rFix i i -irFix. -irFlex -TrFlex i i -rFlex. -ir 

‘^^Seq •— *>^Seq ^ ‘^Seq ’ ‘^Ind ^ ‘^Seq’ -^Ind ^ ‘^Seq ’ • — 

jpFix u jpFiex. p _ pFix y ^Fiex^ ^ ^ _^Fix y ^Fix jg denoted by 

Ar{q). A function symbol c G is called a constant if Ar{c) = 0. 



Definition 1. We define the notion of term over T and V: 

1. IftG Vind (resp. t G VseqA then t is an individual (resp. sequence) term. 

2. If f G (f^sp. f G ^|eqy^> Ar{f) = n, n > 0, and t\, ... fin are individual 
terms, then ffti, . . . ,tn) is an individual (resp. sequence) term. 

3. If f G (resp. f G and ti,...,tn (n > 0) are individual or 

sequence terms, then f{t\, . . . ,tn) is an individual (resp. sequence) term. 

A term is either an individual or a sequence term. 

We denote by V), 7seq(l^, V) and T{T,V) respectively the set of all 

individual terms, all sequence terms and all terms over T and V. 

If not otherwise stated, the following symbols, with or without indices, are 
used as metavariables: x, y and z - over individual variables; x, y and z - over 
sequence variables; u and v - over (individual or sequence) variables; /, g and h 
- over individual function symbols; /, g and h - over sequence function symbols; 
a, b and c - over individual constants; a, b and c - over sequence constants. 

Example 1. Let / G 7 G 9 G , 9 G Ar{g) = 2, Ar{g) = 1. 

1- f_{x,^x,y)) gTi^a{J^,V). 

2- f{x,f{x,x,y))G%eq{T,V). 

3. f{x,g(x)) ^ T(lF, V), because x occurs as an argument of g which is of fixed 
arity. 

4. f{x,g{x,y)) ^ T(lF, V), because g is unary. 



Definition 2. We define the notion of atomic formula, or shortly, atom, over 
V, T and V: 

1. Ifp G Ar{p) = n, n > 0, and ti, . . . ,t„ G 7ind(l^, V), thenp{t\, . . . ,tn) 
is an atom. 

2. If p G and ti, ... ,t„ G T(lF, V), n > 0, then p(ti , . . . , t„) is an atom. 

We denote the set of atomic formulae over V, T and V by A{V, T , V). 

The function symbol / is called the head of the term f{ti, . . . ,tn). We denote 
the head of t ^ V by Tiead{f). The head of an atom is defined in the same way. 

Definition 3. We define the set o/ formulae Tml{V ,T ,V) overV, T and V: 

Eml{V, T, V) := AlfP , T, V) U {^A \ A G EmlfiP, T, V)} 

\J {Ao B \ A,B G Tml{V,T,V), o g {V,A,^,<t^}} 

U {Qv.A I A G Eml(P,E,V), v G V, Qg {3,V}}. 

Free and bound variables of a formula are defined in the standard way. We 
denote by £~ the language defined by IF U 7^. 
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3 Substitutions 

Definition 4. A variable binding is either a pair x ^ t where t G 

and t ^ X, or an expression x ’~ti, . . . , where n> 0, for all 1 < i < n we 

have ti G T{T,V), and if n = 1 then t\ x. 

Definition 5. A substitution is a finite set of variable bindings 

{a;i l-^ti,...,Xn'-^ tn,Xi ^ '“sj, . . . ...,Xm'-^ '"s™, • • ■ ,5^“'}, 

where n,m>0, X\, . . . ,Xn,xi, . . . ,Xm are distinct variables A 

Lower case Greek letters are used to denote substitutions. The empty substi- 
tution is denoted by e. 

Definition 6. The instance of a term s with respect to a substitution a, denoted 
sa, is defined recursively as follows: 

^ ( t, if X 1-^ t G a, 

\ X, otherwise. 

2 ^ f ii, ■ • ■ if T ’~ti,. ..,tn~'ea, n > 0, 

[x, otherwise. 

3. f{h, tn)(J = fiha, tn(j). 

Example 2. f{x,x,y){x a,x '~^,V ^a,f{x),b~'} = f{a,a,f{x),b). 

By Var{Q) we denote the set of all variables occurring in Q, where Q is a 
term or a set of terms. 

Definition 7. Let a be a substitution. 

1. The domain of a is the set of variables T>om{a) = {I \ la ^ I}. 

2. The codomain of a is the set of terms Cod{a) = {la \ I G T>om{a)}. 

3. The range of a is the set of variables: TZan{a) = Var{Cod{a)). 

Note that a codomain of a substitution is a set of terms, not a set consisting of 
terms and sequences of terms. For instance, Cod{{x ^ b,x ^ '~a, a, 5”'}) = {a, b}. 

Application of a substitution on a formula is defined in the standard way. We 
denote an application of ct on A by Fa. 

Definition 8. A term t is free for a variable v in a formula F if either 

1. F is an atom, or 

2. F = ^A and t is free for v in A, or 



^ To improve readability, we write sequences that bind sequence variables between 
and 

® In [23] we consider a more general notion of substitution that allows bindings for 
sequence function symbols as well. That, in fact, treats sequence function symbols as 
second-order variables. However, for our purposes the notion of substitution defined 
above is sufficient. 
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3. F = {A o B) and t is free for v in B and C , where o g {V, A, =J>, or 
4- F = \fuA or F = 3uA and either (a) v = u, or (b) v ^ u, u ^ Varft) and t 
is free for v in A. 

We assume that for any formula F and substitution a, before applying a on 
F all bound variables in F are renamed so that they do not occur in TZan(a). 
This assumption guarantees that for all v g 'Dom{a) the terms in va are free for 
V in F. 



4 Semantics 

For a set S, we denote by S'” the set of all n-tuples over S. In particular, S° = 
{()}. By S°° we denote the set Ui>oS*. 

Definition 9. A structure © for L~ (or, in short, an L~-structure) is a pair 
fp,X), where: 

— T> is a non-empty set, called a domain of &, that is a disjoint union of two 
sets, T>ind and I?seq, written V = I?indW2?seq, where I?ind ^ 0- 

— 2 is a mapping, called an interpretation that associates: 

• To every individual constant c in L~ some element cj ofDind- 

• To every sequence constant c in £~ some element cj ofT>°°. 

• To every n-ary individual function symbol f in L~, with n > 0, some 

n-ary function fx : T>j” ^ ^ T>i„d. _ 

• To every n-ary sequence function symbol f in C~, with n > 0, some 

n-ary multi-valued function fj : T)°° . 

• To every flexible arity individual function symbol f in L~, some flexible 

arity function fx '■ T’ind • 

• To every flexible arity sequence function symbol f in L~, some flexible 

arity multi-valued function fj : T>°° T>°° . 

• To every n-ary predicate symbol p in L~ other than with n >0, some 
n-ary predicate px C 

• To every flexible arity predicate symbol p in L~ some flexible arity pred- 
icate Px C T>°° ; 

Definition 10 . Let © = (P,X) be an C~-structure. A state a over &, denoted 
(T®, is a mapping defined on variables as follows: 

— For an individual variable x, cr®(x) g Hind- 

— For a sequence variable x, cr®(x) g X)°° . 

Definition 11 . Let © = {X>,X) be an C~ -structure and let a be a state over ©. 
A value of a term t in & w.r.t. a, denoted Valfff), is defined as follows: 

— Valf{v) = cr®(v), for every u g V. 

— VaZ®(/(ti,...,t„)) = fx{Valf{ti),...,Valf{tn)), for every g 

T{F,V), n > 0. 
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Definition 12. Let v be a variable and cr® be a state over an C~-structure &. 
A state r?® is a ri-variant of a® iff'd‘^{u) = <j'^{u) for each variable Uy^v. 

The set TV = {T,F} is called the set of truth values. The operations ^tv, 
VtV) AtV) =^tV) ^tv are defined on TV in the standard way. 

Definition 13. Let & = (T,T) be an C~ -structure and a be a state over ©. A 
truth value of a formula F in & with respect to a, denoted Valf{F), is defined 
as follows: 

- Valfipih, ...,tr,)) = T tjf (Valfih), Va/f (t„)) C pj. 

- Valfih « t 2 ) = T iffValfih) = Valfit^). 

- VaZ®(-T) = -TvVal®(T). 

— VaZ® (Ti o F 2 ) = Va/® (Ti) o^v Val® (T 2 ), where o g {V, A, <14>} 

— Valf (yvF) = T iffValf(F) = T for every V® that is a v-variant of . 

— Valf (3vF) = T iffVal^ {F) = T for some V® that is a v-variant of a'^ . 

In Definition 9 we required the domain T to be a disjoint union of two sets 
Tind and Tseq- It is justified, since on the syntactic level we distinguish between 
individual and sequence terms, and it is natural to reflect this distinction on the 
semantic level. In the next section we define a calculus that is complete with 
respect to this semantics. Many classical results remain valid as well. 

On the other side, one would naturally expect that a sequence term represents 
a finite sequence of individual terms. In other words, the intuition would suggest 
that the sequence terms should be interpreted as finite sequences of individual 
elements of the domain. This intuition can be easily captured by structures 
whose domain consists of individual elements only. We call such structures the 
intended structures. In Section 6 below we show relations between induction with 
sequence variables and intended structures. 



5 The Gentzen-Style System G~ 

In this section we present a Gentzen-style sequent calculus for C~. 

Definition 14. A sequent is a pair of sequences of formulae. A sequent {F, A) 
is denoted by F ^ A. 

In a sequent T — > Z\, T is called the antecedent and A is called the succedent. 
If T is the empty sequence, the corresponding sequent is denoted as ^ Z\. If Z\ is 
empty, the corresponding sequent is denoted as T — If both F and A are empty, 
we have the inconsistent sequent Below the symbols F,A,A will be used to 
denote arbitrary sequences of formulae and A,B to denote formulae. Note that 
F,A,A are sequence variables on the meta level. The set of free variables of a 
formula A is denoted by FVar{A). 

Definition 15. A position within a term or atom E is a sequence of positive 
integers, describing the path from ’Head{E) to the head of the subterm at that 
position. By E[s]p we denote the term or atom obtained from E by replacing the 
term at position p with the term s. 
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Definition 16. The sequent calculus G“ consists of the following 17 inference 
rules . 

r,A,B,A^A r^A,A,A F^A,B,A 

(A H A) 

b,aab,a^ A r ^ a,aab,a 



r,A,A^ A r,B,A^ A r ^ A, A, B, A 

(V H V) 

r,A\/ B,A^ A r ^ A,A\/ B,A 



r^A,A,A r,B,A^A r,A^A,B,A 

r,A^B,A^A ^ r^A,A^B,A^ 



r,A^A,A A,r ^ A,A 

r,-^A,A^ r ^ A,^A,A^~" 

In the quantifier rules below 

1. X is any individual variable; 

2. y is any individual variable free for x in A and y ^ TVar{A) \ {x}; 

3. t is any individual term free for x in A; 

4- X is any sequence variable; 

5. y is any sequence variable free for x in A and y ^ TVar{A) \ {a;}; 

6. si, . . . , Sn, n>Q, is any sequence of terms each of them free for x in A. 

r,A{xi-^t},\/xA,A^A r ^ A, A{x 1 -^ y}, A 

(Vi Vi) 

r,\/xA,A^A r^A,\/xA,A 



r, A{x 1 -^ y},A ^ A r ^ A, A{x t}, 3xA, A 

(3i ^) ( > 3i) 

r, 3 xA, Z\ ^ yl r ^ A, 3 xA, A 



r, A{x '”si, . . . , s„”'}, Va;Ai, Zi ^ yl B ^ A, A{x y},A 

(Vs (^ Vs) 

r,\/xA,A^A r^A,\/xA,A 



r, A{x 1-^ y}, A ^ A r ^ A, A{x '”si, . . . , Sn”'}, 3xA, A 

(3s ^) (^ 3s) 

r, 3xA, Z\ ^ yl r ^ A, 3xA, A 

In the rule («) below A is an atom and p is a position. 

r,{s ^ t A A[s]p) ^ A[t]p A 
A 
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Note that in both the Vi)-rule and the (3i — >)-rule, the variable y does 
not occur free in the lower sequent. Similarly, in both the {—>■ Vs)-rule and the 
(3g ^)-rule, the variable y does not occur free in the lower sequent. 

The axioms of G“ are all sequents F ^ A such that F and A contain 
a common formula, and sequents of the form F —> A, s ^ s, A. Validity and 
provability of sequents are defined in the standard way. 

The following version of Godel’s extended completeness theorem holds for 
the calculus G“: 

Theorem 1 (Completeness of G“). A sequent (even infinite) is valid iff it 
is provable in G“. 

The classical results like Lowenheim-Skolem, Compactness, Model Existence 
theorems, and Consistency Lemma remain valid for C~. 

The calculus G“ has many nice proof-theoretic properties, but is not suited 
for implementation because of too high non-determinism. It is a well-known 
problem for many sequent-based calculi (like, for instance, for the classical LK“ 
calculus). Degtyarev and Voronkov [14] survey the methods to overcome it. In 
our case, a variant of basic superposition with ordering and equality constraint 
inheritance proposed in [27] seems to be a reasonable alternative of G“, taking 
into account the fact that unification with sequence variables and sequence func- 
tions is infinitary but decidable [23]. This approach for theories with sequence 
variables, but without sequence functions has already been considered in [22]. 
To do the same for theories with sequence variables and sequence functions one 
needs to introduce a reduction ordering on terms involving sequence variables 
and functions, and an efficient algorithm for solving ordering constraints. This 
is a subject of further research and lies beyond the scope of this paper. 

Note also that predicate logic with sequence variables and sequence function 
symbols can be encoded as a special order-sorted first-order theory. It requires 
introducing into the language an additional binary function symbol for construct- 
ing sequences, a constant for the empty sequence, and adding to the theory the 
corresponding axioms. Details of the translation can be found in [24]. 



6 Induction with Sequence Variables 

In this section we develop a machinery to capture the natural intuitive meaning 
of sequence terms: representation of finite sequences of individual terms. On the 
semantic level it amounts to considering the intended structures, and on the 
inference rules level it leads to introducing induction. 

We start with the definitions of inductive domain and intended structure. 

Definition 17. let 6 = {F>,F) be a structure for the language L~ such that 
T’seq = 0- Then & is called an intended structure for L~ and V is called an 
inductive domain. 

Note that Herbrand structures are not intended structures for C~. We will 
write A[v] to indicate that the formula A contains a free occurrence of v. 
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Below we will use a special flexible arity function symbol / that satisfies the 
following axioms: 

Va;VxVl/ ~^{f{x,x,y) « /()), 
yxyyVxVy f{x, x) « f{y, y) x y A f{x) « f{y), 
yxyyWxyy f{x, x) « f(y, y) AA f{x) « f{y) Ax^y, 

VsVy (fix) « f{y) A A{z ^ x}) ^ A{z ^ y}, 

where A is an arbitrary formula. 

Definition 18. The well-foundecA induction principle for sequence variables is 
formulated as follows: 

yx (Vy if(x) >- f{jj) A{x 1 -^ y}) A\x\) Vx A\x] (WFI) 

where >- is a well-founded ordering defined for terms with the head f. 

It is not hard to show that the well-founded induction principle is valid. Since 
well-foundedness is an undecidable property, we will develop syntactic instances 
of the WFI principle that avoid direct reference to arbitrary well-founded rela- 
tions. We give below some practically useful examples of such instantiation that 
have been used in the case studies [9, 10]. 

We start from auxiliary notions. 

Definition 19. The case distinction rule from the left is the formula 
{A{x ^ A yyyy A{x ^ ^y, y^}) ^ Vx A[x] (LCD) 

The LCD rule is not valid, as the following example shows: 

Example 3. Let A\x] in LCD be the atom pfx). Take a structure © = {T>,X) 
such that Hind = {«}, 2^Seq = {b} and px contains all the finite tuples over T> 
whose first element is not b. Then LCD is false in 6. 

However, the following theorem holds: 

Theorem 2. LCD is true in every intended model. 

Definition 20. The suffix ordering l^suf is defined on terms with the head f : 

VsVy (/(x) >-sn{ f{y) aa 

3z3z f(x) « f(z,z) A (f(z) « f(y) V f{z) ^suf f{y))) (SO) 

Suffix ordering is well-founded and has the property that any term of the form 
f{ti, . . . ,tn), n > 0, which is not minimal with respect to )^suf, has individual 
terms as its first k arguments for some 1 < fc < n. 

^ Also called Noetherian. 
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Definition 21. The structural induction from the left is the formula 

{A{x ^ AWyMy {A{x <-^y}^ A{x ^ '"y,!/"'})) Vx A\x]. (LSI) 



LSI can be obtained syntactically from SO and the instances of WFI and 
LCD: If we take 



B[x\ 

WFP 

LCD’ 



A{a 



■= Vy (fix) ^Suf f{y) 

:= Vx B[x] ^ Vx A\x], 

:= {B{x ^ A VzV^ B{x 

then the following theorem holds: 

Theorem 3. The sequent SO, LCD’, WFF 



y}) 

Vx B[x], 

■ LSI is provable in G® 



We proved this theorem with the help of one of the provers of the Theo- 
REMA system. First, we proved LSI from SO, LCD’, and WFF automatically 
by the Theorema prover for predicate logic using metavariables, called PLM 
[20], and then translated the output into the G“ proof. (The calculus imple- 
mented in PLM is different from G“: it uses metavariables and has a restricted 
(incomplete) sequence unification algorithm for sequence metavariables.) 

LSI has the following important property: 

Theorem 4. LSI is true in every intended model. 

The next theorem, in fact, shows that LCD can be proved from LSI: 

Theorem 5. The sequent LSI LCD is provable in G“. 

Now we turn LSI into the inference rule: 

r ^ A, A{x A 'iy'iy (^{x y} ^ A{x ’~y,y~'}), A 



r^Z\,VxA[x],T 

Soundness of G“ and Theorem 4 imply the following result: 



(Slleft) 



Theorem 6. If a sequent is provable using (Sfieft) and the inference rules of 
G“, then it is true in every intended structure. 

In the similar way we can get another instance of WFI: 

Definition 22. The case distinction rule from the right is the formula 

{A{x ^ A VjA/y A{x ^ ^y, i/“'}) ^ Vx A[x] (RCD) 

The prefix ordering )^pre is defined on terms with the head f as follows: 

VsVy (/(x) ^Pre f{y) AA 

3z3z f(x) « f{z, z) A (/(V) « f{y) V f(z) >-pre f{y))) (PO) 

The structural induction from the right is the formula 
{A{x 1 -^ A yyiy {A{x <-^y}^ A{x '~y, y"'})) Vx A\x] . (RSI) 
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Like LSI, we can turn RSI into an inference rule: 
r ^ A, A{x ^ A {A{x 1-^1/}=^ A{x ^ ’~y, y~'}),A 

r ^ Ayx Am,A 

The counterpart of Theorem 6 holds for ( S Right )• 

Another useful well-founded ordering on terms with sequence variables is the 
length ordering defined as follows: 



(SRight) 



'^xiy if{x) )^Len f{y) ^ ^zBz f(x) « f{z, z) 

A(/(y) « /() V 3u3u if{y) « f{u,u) A f{z) ^Len /(m))) (LO) 



If we instantiate the ordering A in WFI with Ahen, we get an instance of 
WFI called well-founded induction principle with the length ordering: 

VT (Vy {f{x) ^Len f{y) ^ ^ y}) A\x\) ^ Vx A\x] (WFILO) 



The next example shows that WFILO is not valid. 

Example 4- Let A\x] be an atom p{x) with the flexible arity predicate symbol 
p. Let © = {T>^X) be a structure whose domain T> is the set of all ground terms 
built from an individual constant c, sequence constant c and a flexible arity 
function symbol /. The assignment X is defined so that it maps each ground 
term to itself and the predicate Auen to the same predicate on V. As for px, 
let it be a flexible arity predicate on X) that contains all the tuples over X) 
except (c, c). Then Valf {f{c,c) I^Len /() p{)) p(c, c)) = F which implies 

that Valffix (Vp f{x) Axen fiV) => p{y)) p(x)) = T. On the other side, 

Valfiyx p(x)) = F. Therefore, WFILO is false in 6 with respect to ct®. 

Nevertheless, WFILO is satisfied by any intended structure: 

Theorem 7. WFILO is true in any intended structure. 

Instantiating / in WFILO with the tuple constructor we get the tuple in- 
duction principle formulated in [10]. 

WFILO can be turned into an inference rule: 



r,LO ^ Z\,Vx (Vy (/(x) ALen f{y) A{x ^ y}) A[x]),A 

r, LO ^ A, VxA[x], A 



(WFRen) 



The counterpart of Theorem 6 holds for (WFRen). 

The calculus G“ does not contain the cut rule, but we need it in induction 
proofs. 



r^A,A,A r,A^A,B,A 
r ^ A, B, A 



(Cut) 



Cut rule forms a basis for Theorema conjecture generation algorithm and 
the cascade method introduced by the second author in [8]. Informally, the cas- 
cade method works as follows: Given a goal G and knowledge base K, if an 




Predicate Logic with Sequence Variables and Sequence Function Symbols 217 



attempt of proving G using K fails, cascade method tries to analyze the fail- 
ing proof situation, and using the conjecture generation algorithm generates a 
conjecture C such that G might be provable using K U {G}. After that, it tries 
to prove G from K, in the similar manner. Thus, this procedure corresponds 
to the application of the cut rule, and the conjecture generation algorithm can 
be considered as an intelligent heuristics of selecting “useful conjectures” among 
infinitely many possible ones. 

At the end of this section we provide an example of proving by induction 
with sequence variables: reverse of a reverse of a list coincides with the original 
list. We give a “human-readable” version of the formal proof. 



Example 5. We want to prove 

\/x rev{rev{{x))) = (x) (1) 

under the assumptions 

rev{{)) = 0, (2) 

\/x rev{{x)) = (a;), (3) 

VaiVy rev{{x,y)) = rev{{y)) rev{{x)), (4) 

\/x\/y (x) X (y) = (x,y), (5) 

Vaidy rev{{x)) = (y). (6) 



The formulae (2), (3) and (4) define the reverse function, (5) is a definition 
of concatenation, and (6) states that reversing a list gives again a list. Then the 
proof of (1) proceeds as follows: 

Induction base: 

rev{rev{{))) = by (2) 
revK)) = by (2) 

()• 

Induction hypothesis: We assume 

rev{rev{{c))) = (c). (7) 

Induction step: We have to show that rev{rev{{c,c))) = (c, c): 

rev{rev{{c,c))) = by (4) 
rev(rev({c)) x rev{{c))) = by (3) 
rev{rev{{c)) x (c)) = by (6) 
re?;((7(c)|x (c)) = by (5) 
rez;((/(c),c)) = by (4) 
rev{{c)) X rev{{f{c))) = by (6) 
rev{{c)) X rev{rev{{c))) = by (7) 
rev{{c)) X (c) = by (3) 

(c) X (c) = by (5) 

(c,c) 

which finishes the proof. Note that (6) is used once to rewrite from left to right, 
and in the other case from right to left. 
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7 Conclusion 

We described a syntax, semantics and inference system for a logic with sequence 
variables and sequence functions. The calculus G“ for such a logic extends the 
LK“ calculus and has many nice proof-theoretic properties. Furthermore, we 
considered special structures, called intended structures, to reflect the intuition 
behind sequence variables: abbreviation of finite sequences of individual terms. 
We formalized this intuition using induction, and defined several versions of 
induction rules. The interesting feature of logic with sequence variables and 
sequence functions is that there is no need in introducing constructors to define 
inductive data types. This information is “built-in” into the logic itself. 
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Abstract. As the amount of online formal mathematical content grows, 
for example through active efforts such as the Mathweb [21], MOWGLI 
[4], Formal Digital Library, or FDL [1], and others, it becomes increas- 
ingly valuable to find automated means to manage this data and capture 
semantics such as relatedness and significance. We apply graph-based ap- 
proaches, such as HITS, or Hyperlink Induced Topic Search, [11] used for 
World Wide Web document search and analysis, to formal mathemati- 
cal data collections. The nodes of the graphs we analyze are theorems 
and definitions, and the links are logical dependencies. By exploiting this 
link structure, we show how one may extract organizational and related- 
ness information from a collection of digital formal math. We discuss the 
value of the information we can extract, yielding potential applications 
in math search tools, theorem proving, and education. 



1 Introduction 

Invaluable progress has been made in the development of digital libraries of 
math-ematics [1, 3, 4, 15, 21]. Such progress also includes content and 
presentation-specific representations of mathematical knowledge [13, 14, 16], in- 
cluding architectures for exchanging mathematical content. These efforts are 
bringing together otherwise disparate collections of formal mathematics, and 
providing rich access to mathematical knowledge. 

We are interested in providing services to users and designers of formal math- 
ematical digital libraries. One such service is the ability to search for theorems 
or other mathematical objects with respect to their relationship to other theo- 
rems or objects in a given collection. The kinds of inter-object relationships may 
include similarity of theorem statements, similarity of proof methods, even sim- 
ilar levels of difficulty, particularly useful in user-model based approaches and 
education. Another service we wish to provide is finding core or basic theorems 
and axioms with respect to the surrounding collection, theorems that cover or 
utilize heavily this core content, or theorems that seem to be authoritative and 
representative of a particular topic. Object dependencies of the kinds stored in 
the FDL can aid us in building these services. 
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Our approach is to use the mathematical objects and their logical dependen- 
cies to build a directed graph, and apply graph-theoretic algorithms to under- 
stand and extract information from the structure. Formal mathematical lemmas 
and their dependencies on other lemmas or definitions in their proofs form the 
nodes and edges of a directed graph respectively, as do web pages and hyper- 
links on the Internet. Previous research has demonstrated effective methods for 
gathering relatedness and other semantic information about web pages on the 
Internet by operating on this directed graph. Popular eigenvector-based methods 
that are effective in web search by finding authoritative sources include Klein- 
berg’s HITS algorithm and Google’s PageRank [9]. In addition to abilities to rank 
important objects, capabilities to cluster or organize data into groups based on 
the graph structure have been developed and exploited. Web Trawling [12] uses 
a graph-theoretic approach to enumerate communities on the web, based on the 
findings of densely bipartite sub-graphs. Recent work in [17] finds communities 
in networks by iteratively removing detectable edges from the network to divide 
the collection into related groups. 

Automatically categorizing or grouping related theorems in a formal digital 
library is one goal we are pursuing. In this work, however, we investigate, in 
general, the use of link analysis methods in the formal domain. While we restrict 
our studies to objects that were developed using the NuprlS refiner and are stored 
in the FDL, other interactive theorem provers make the same kinds of analysis 
possible, by having dependency information accessible. Such systems include 
Coq, MetaPRL, PVS, and others. Since we operate only on logical dependencies 
in this analysis, any collection of mathematics from which we can extract a 
dependency graph would be suitable. 

We apply Kleinberg’s HITS algorithm to collections of formal mathemat- 
ics in Section 2, where we also describe the link distributions of our chosen 
formal math data sets. In Section 3, we present a variation of HITS that has 
been tailored specifically for the formal math domain, observing varying levels of 
authoritativeness in this domain. We discuss future work in Section 4 and con- 
clude in Section 5, including ways that this work opens possibilities for further 
automation and improvements in managing and understanding a digital library 
of mathematics. 



2 HITS and Dependency Graphs 

In the World Wide Web domain, hubs are web pages that point to a large number 
of authorities and authorities are pages pointed to by a large number of hubs. In 
the mathematical domain, our intuition tells us that hubs are proofs or lemmas 
that depend logically on a large number of authoritative lemmas or definitions, 
and authorities are the core definitions or theorems that are depended upon by 
a large number of hubs. 

Kleinberg’s HITS algorithm demonstrates how to find hubs and authorities 
on the web. After a base set of web pages and links is generated, a directed 
graph, G = (V,E), is constructed where the vertices V are the web pages, and 
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the edges E are the hyperlinks. Hubs and authorities are found by assigning hub 
and authority weights to the vertices, and updating these values for k iterations, 
for some large enough k so that the process approaches equilibrium, or the weight 
vectors become nearly stable. If A is the adjacency matrix of the graph G, and 
vectors x and y are the authority and hub weight vectors, then x and y converge 
to the principle eigenvectors of A and AA^ respectively. Then, the web pages 
with the c largest coordinates in x and in y when they have converged are deemed 
to be the c best authorities and hubs respectively. 

2.1 Implementation and Design Choices 

We implemented the algorithm in LISP, and ran the code inside of Cornell’s FDL 
on two different collections of formal mathematics that belong to that library: 
the NuprlS Standard collection [2] , and the Event Structures collection [8] . These 
two collections were easily accessible to us and also presented a good contrast 
for measuring and evaluating our results. Large collections of PVS content also 
currently reside in the FDL, which would have been nice to contrast with Nuprl 
libraries, but we did not have the dependency information yet accessible for the 
PVS material, though in the future we hope to experiment with other collections. 

In constructing the graphs, we chose theorems and definitions to be vertices 
of the graph. In further analyses, we plan to add rules as well. Tactics, and 
code objects were also potential candidates and may of interest for different 
kinds of information, such as relating proof styles. We restricted the edges to 
be representative of logical dependences. Again, other kinds of dependencies, 
including pointers to documents or comment objects, could be of interest as 
these links become more prominent. 

We considered how to define a logical dependency in the context of this link 
analysis. We took the logical dependencies of a theorem to be all of the objects 
that were needed to complete the proof of the theorem. These include definitions 
and other theorems. It is a matter of style whether a user chooses to create a 
new theorem in order to prove a current one, or not. The former would create a 
dependency between two theorems where the latter would not, by self-containing 
the proof argument. We chose to use only the direct dependencies, as maintained 
by the FDL. By direct, we mean theorem A depends on theorem B if and only 
if B is directly pointed to in the proof of A. Indirect dependencies of A would 
then include the direct dependencies of B. While growing the graph by adding 
dependencies based on dependency transitivity might account for the variable 
proof designs, we would lose the structures that mimic the development of the 
theory, and likewise, the progressive level of expertise needed to understand 
a theory. We thus define the out-links of a node to point to its direct logical 
dependencies. 

For the theorems, logical dependencies were gathered from the primitive 
proofs of the theorems which were created during refinement in the Nuprl proof 
system. Primitive proofs typically have too much detail to be desirable for read- 
ing, and many users prefer to read the tactic-level proofs. Nevertheless, primitive 
proofs contain all of the logical information of the proof execution. And in fact. 
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the Nuprl primitive proofs are available online as part of the HELM project [3]. 
We do not include any out-links for the definitions. Definition objects do not 
have logical dependencies, that is, any definition is valid and they may only de- 
pend on a proof if for example, we would have considered extracts as definitions. 
However, definitions, like theorems are built up iteratively, and the definition 
for greatest common denominator, for example, depends on the definition of di- 
vides. These kinds of semantic dependencies are also accessible in the FDL. To 
understand authoritative objects with respect to definitions, we could capture 
the definition-definition dependencies, as these dependencies reveal when two 
definitions are related. The number of definitions with respect to theorems is 
small and we focus here on the logical links only. 

2.2 NuprlS Standard Collection 

The NuprlS Standard collection contains theories about integers, numbers, lists, 
booleans, and more. Information about its dependency graph is in Table 1. 



Table 1. NuprlS Standard Dependency Graph Data. Most fields should be clear. The 
assortativity of a network was defined by Newman in [18] and is a measure of the 
variance of the link distribution, or degree-degree correlations often used in social- 
network analysis. In practice, r is positive for social networks, where the nodes represent 
people, and negative for non-social networks such as the world wide web, power grids, 
and biological networks 



Nodes 


Theorems 


Definitions 


Max. Outlinks 


Max. Inlinks 


Edges 


Assortativity 


811 


646 


165 


58 


637 


8765 


-0.2949 



Log-log density plots (using natural log) for the out-links and in-links are 
shown in Fig. 1. We observe a short incline until a peak is reached and then a 
decline after a peak value is met in the out-link distribution. This demonstrates 
a characteristic number of dependencies for the theorems. Though difficult to 
observe with such large variation, the tails are much longer for the in-links (we 
removed the end of the tail so that more data was visible since there we definition 
nodes with up to over 600 inlinks), which happens to be typical of the World 
Wide Web links. 

The power law distribution, which appears as a straight line in log-log density 
plots, is prevalent in many growing real-world networks, such as power grids, and 
the Internet [5] . Our data does not closely fit a power law over the entire set of 
degrees, but it is nearly linear over certain intervals of degree values: after the 
peak in the out-link graph, and also in the earlier part of the in-link graph. 

Cumulative distributions shed more visual information as to the shape and 
nature of our graphs. Log-log plots of the cumulative distributions are shown in 
Figure 2. 

In the graph on the left, we observe a peak around 5-6, which is the same 
peak visible in the earlier graph. Also, the lower range of the in-link function 
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NuprlS Standard Out-link Distribution 


NuprlS Standard In-link Distribution 
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Fig. 1. Nuprl5 Standard Log-Log Density Plots 
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Fig. 2. NuprlS Standard Cumulative Log-Log Plots 

follows a straight line, after which the data is very noisy, as shown in Figure 1 
on the right. 

From the above graphs, we observe a characteristic peak in the theorem out- 
links. Where this peak occurs may vary depending on the theory topic, or the 
complexity. 

2.3 Nuprl 5 Standard HITS Results 

In this section we include results from applying the HITS algorithm to our 
network. 

The names of the top hubs and authorities of the NuprlS Standard collec- 
tion of the FDL are listed below in decreasing order. As expected, the authorities 
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are core, simple definitions, and the hubs are major theorems which depend on 
them. 



Table 2. Nuprl 5 Standard Hubs and Authorities 



Authorities 


member, all, prop, implies, and, iff, rev .implies, false. 


Hubs 


rem_mag_bound, select JistifyTd, listify.wf, rem_eq_args.z, 
rem_base_case.z, select Jirstn, listify .length, mod.bounds, modulus.wf 



The authorities are the most fundamental and critical definitions in the Nuprl 
type theory. Hubs are objects from the list theory and the integer theory, two 
dominant theories in the collection. The authority values were primarily those 
with the greatest in-links, and likewise the hubs had large numbers of out-links. 
This was a trend, but not an exact representation. Rem_mag_bound, which states 
that the remainder of a divided by n is less than n, for example, has 51 out-links 
while the maximum has 56. 

In addition to finding hubs and authorities, the HITS algorithm presents 
an eigenvector-based approach to finding clusters or communities in a graph. 
While the hubs and authorities can be found from principal eigenvectors, the 
best hubs and the best authorities from the non-principal eigenvectors of A 
and AA^ reveal communities. Furthermore, the communities that correspond to 
greater eigenvalues, are typically stronger. We looked for the vertices with the 
greatest hub weight and authority weight in the non-principal eigenvectors with 
the greater eigenvalues. These often are semantically related in practice. While 
the individual non-principal eigenvectors are thus a direct way to expose further 
structure in the data, we note that Ng et al. [19] observe instabilities in some 
cases in the use of these eigenvectors, and recommend more generally studying 
subspaces spanned by the non-principal eigenvectors. 

Since the Nuprl Standard library has already been structured by humans 
around topics including lists, booleans, integers, and more, we compared the 
clusters found via the HITS method to the human-made categories, or topics. In 
some cases, the communities found could be considered as further refinements on 
the human-made topic structure. We set threshold values based on trial an error 
(an optimal threshold can perhaps be learned) as to when the corresponding 
eigenvalue was large enough to represent a community. The first four communi- 
ties found are listed below. 

The first is about lists, the second about recursive functions, and the latter 
two about Fibonacci numbers and atomicity in number theory. The objects in 
the clusters fell mainly in the human-made number theory category, and were 
often refinements on these human made categories. 

Nuprl 5 Standard Number Theory Example. Hub and authority values 
can often best be utilized when you have already chosen a topic, as is the case 
in their use in Internet search. Typically, HITS seeds its search by growing its 
starting set of nodes. We extracted a sub-collection from Nuprl5 Standard about 
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Table 3. Nuprl5 Standard Communities 



Community 1 


listify .length, select Jistifyjd, int.seg_ind, select _append_front, 
decidable__ex_int_seg, or, decidable, so.applyl 


Community 2 


finer .format ion, fincr.wf, fincr.wf2, equiv.rel.functionality.wrt .iff 


Community 3 


fib.coprime, gcd.sat.gcd.p, gcd.sat.pred, fib.wf, gcd.wf, ycomb, 
not.wf 


Community 4 


atomic.char, assert. of. eq.int, prime.elim, assert.of.eq.atom, le.wf 



numbers, seeded this collection by recursively adding dependencies, and ran the 
HITS algorithm with the new subgraph. Information about this subgraph is in 
Table 4. 



Table 4. NuprlS Number Theory 



Nodes 


Theorems 


Definitions 


Max. Outlinks 


Max. Inlinks 


Edges 


Assortativity 


328 


260 


68 


56 


257 


3397 


-0.2848 



The entire graph, dense due to many connections to core definitions is difficult 
to visualize in a confined space. Removing all of the definitions from the graph, 
as well as well-formedness theorems, which correspond to each definition to say 
it’s well formed, we obtain a more visible graph in Figure 3. 




Fig. 3. Number Theory Theorem Dependencies 
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The top hubs and authorities of the NuprlS Number theory collection includ- 
ing all of its dependencies are listed below in decreasing order. 

Table 5. NuprlS Number Theory Hubs and Authorities 



Authorities 


member, all, implies, prop, and, iff, revTmplies, false, not 


Hubs 


rem_mag_bound, gcd_sat_gcd_p, gcd_sat_pred, fib_coprime, 
fib_wf, absvaLelim, absvaLpos, absvaLeq, gcd_ex_n 



Since we seeded our search by adding objects that Number theory depends 
on, our authorities are similar to those from the entire Standard collection. If 
we wanted to know core definitions within number theory, we can eliminate the 
seeding step to get the following authorities: divides_wf, gcd_p, assoced, divides, 
assoced-weakening, assoced-wf. 

Some of communities found from the HITS’ eigenvector approach are listed 
below. 



Table 6. NuprlS Number Theory Communities 



Community 1 


divides_of_absvals, absvaLassoced, absvaLwf 


Community 2 


chrem_exists_aux_a, gcd_ex_n, chrem_exists_aux, atomic_char, 
prime_elim, gcd_exists_n, bezout_ident_n, chrem_exists 


Community 3 


div_3_to_l, div_2_to_l, div_4_to_l, divide_wf, nequal 


Community 4 


eqff_to_assert, eqtt_to_assert, assert _of_bnot, assert_of_band, 
prop 



These communities are about absolute value, Chinese remainder theorem, 
division, and assertion respectively. Again, the contents are not so relevant. 
However, we observe that the names of objects within the groupings tend to 
be quite similar to one another, and these similarities in naming can be taken 
as indicative of human judgment that the objects themselves are related. 

2.4 Event Structures Collection 

This Event Structures collection was developed by Dr. Mark Bickford, a mem- 
ber of both ATC-NY, a subsidiary of Architecture Technology Corporation, and 
Cornell’s PRL Group. The objects in it define and support a logic of events, de- 
scribing a semantics for distributed systems. Information about this collection’s 
dependency graph is in Table 7. 

Log-log density plots (using natural log) for the out-links and in-links are 
shown in Figure 4. 

As in Figure 3, the functions plotted in Figure 4 are not quite linear, though 
probably are in a subset range. The data is noisy for objects above some link 
threshold. Again, we look at the log-log cumulative distributions for better clarity 
in Figure 5. 
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Table 7. Event Structures Dependency Graph Data. Fields are the same as in Table 1. 



Nodes 


Theorems 


Definitions 


Max. Out-links 


Max. In-links 


Edges 


Assortativity 


1795 


1306 


489 


210 


708 


16648 


-0.15896 



Event Structures Out-link Distribution 



Event Structures In-link Distribution 




Fig. 4. Event Structure Log-Log Density Plots 



Event Structures Out-link Cumulative 
Distribution 




LOGLINKS 



Event Structures In-link Cumulative 
Distribution 




LOGLINKS 



Fig. 5. Event Structure Cumulative Log-Log Plots 



The out-link distribution is steeper for the Event Structures collection than 
for the Nuprl Standard. Two factors could contribute to this. First, the Event 
Structures is actually built on top of the Standard collection, though the Stan- 
dard collection is not included in its graph. It is an advanced collection, with 
large proofs about a specific topic, rather than a basic introductory collection 
that has more gradual variability. Second, the Nuprl Standard collection was 
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built by several developers, and Dr. Bickford was the sole developer of the Event 
Structure proofs. He may have a proof signature style that may be somewhat 
evident in various structures of the graph. There is less of an initial incline in 
the out-link distribution, which is likely due to the fact that was built on top of 
another collection. The tails are again much longer for the in- links than for the 
out-links. 



2.5 Event Structures HITS Results 

Below we include results from applying Kleinberg’s HITS algorithm to our net- 
work. 

The names of the top hubs and authorities of the Event Structures collection 
are listed below in decreasing order. The names of the objects are less informative 
than in the NuprlS Standard, but the objects’ contents are not entirely relevant. 
The authorities are fundamental lemmas, and the hubs are larger proofs which 
depend on them. 



Table 8. Event Structures Hubs and Authorities 



Authorities 


Id_wf, Knd_wf, IdLnk_wf, id-deq_wf, fpEwf, fpf-cap_wf , Kind-deq_wf, 
fpf-dom_wf, fdf-trivial-subtype-top 


Hubs 


R-compat-base, R-Feasible-Dsys, sends-rule, pre-rule, d-feasible-world, 
R-sends-rule, R-interface-base, R-Feasible-action, R-Dsys-base-wf 



Several communities found are listed below. It is difficult to measure the 
strength of these communities. We include only their names, inferring that the 
developer used a naming scheme such that similarly named objects are similar. 
While it is not apparent what the communities below entail, it is evident that 
they are related by name. 



3 Stratified Authority Weighting 

While the hubs and authorities method assigns weights to vertices at only two 
levels (hub and authority), we note that there are intermediate levels of author- 
itativeness in the formal math domain. Math collections, unlike collections of 
pages on the web, consist of a small number of known kinds of objects that 
demonstrate varied discrete levels of authoritativeness. These kinds, or cate- 
gories, are definitions, rules, theorems, proofs, and perhaps others, depending 
on the theorem prover and its implementation, such as extracts or hypotheses, 
or conjectures. Furthermore, formal theories are often built up in a step-like, or 
modular fashion. For these reasons, we wish to consider levels of authority. 
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Table 9. Event Structures Communities 



Community 1 


d-feasible-world, better-d-comp-step, d-comp-step2, d-comp-step, 
d-comp_wf, deq_wf 


Community 2 


Rpreinit-P_wf, Rpreinit-init_wf, Rpreinit-ds_wf, Rpreinit-T_wf, 
Rpreinit-loc_wf, Rpreinit-a_wf, Rpreinit?, Rpreinit?_wf, Rpreinit-ds, 
Rpreinit 


Community 3 


Reffect-Lwf, Reffect-ds_wf, Reffect-x_wf, Reffect-T_wf, 
Reffect-loc_wf, Reffect-knd_wf, Reflect?, Reffect?_wf 


Community 4 


Rframe-loc_wf, Rframe-T_wf, Rframe-L_wf, Rframe-x_wf, 

Rframe?, Rframe?_wf 

prop 


Community 5 


Lcontains-disjoint, Lcontains_append3, Lcontains_append2, 
Lcontains_append, l_contains_wf, Lcontains-appendd, Lcontains 
prop 



3.1 Authority and Hub Weight Levels 

We observe that the authority and hub weight values don’t necessarily degrade 
naturally, and instead the graphs look somewhat step- like. Figure 6 shows a plot 
of the authority weights for the NuprlS Standard definitions and theorems. 




I 7 O It M 37 43 4« M *1 •? 79 7* H II t7 

Node 



Fig. 6. Authority Weights 



There are a couple small minor plateaus. The lower plateau, at around .7 
shows the importance of the booleans, including objects such as bfalse, btrue, 
or, ifthenelse, and true_wf. 

Next we consider only theorems, excluding wellformedness theorem, which 
yields step-like hub weighting. Figure 7 shows hub weights for a subset of stan- 
dard theorems including integer theories, number theory, list theory, and their 
dependencies. 

Since the Standard library is a basic collection, we expect to find more levels 
when combining collections built on top of Standard. Dr. Bickford built an ex- 
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Fig. 7. Hub Weights 



tended list theory, utlizing NuprlS Standard, and we plot the hub and authority 
weights for this collection, combined with its dependencies in Figure 8. 




Fig. 8. Extended List Theory Hub and Authority Weights 

We do observe slightly more structure in the hubs graph for list theory, show- 
ing its modularity. In comparing these graphs to Figures 6 and 7, we observe 
that there is a potentially characteristic difference between the distribution of 
hub weights and the distribution of authority weights. 

3.2 Dependency-Based Levels 

Instead of using HITS to find levels, we can a priori define levels based on the 
dependencies of the objects. We adopt the following definition of level. 

Level 0 contains all objects that have no dependencies. Level i contains 
all objects x, such that x is not in level j for any j < i, and x depends 
only on objects in levels 0, . . . , fc for fc < j. 
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Using this definition of levels, the NuprlS Standard collection contained a 
total of 19 levels. All of the definitions were in Level 0. In the Event Structures 
library there were a total of 31 levels. Distributions of the levels are shown in 
the Figure 9. 




Fig. 9. Level Distribution 



The high peaks are most interesting. These graphs reiterate in depth what we 
saw earlier in breadth that there is some characteristic depth (level) of proofs, 
just as there was in breadth (link degree). One’s proof style may influence the 
level where there is a peak. The peak on the right is particularly noticeable; it 
suggests that when stratified by depth, the graph exhibits a “wide” region in 
the middle. In this way, it can potentially be viewed as an interesting analogue, 
for acyclic graphs, of the “bow-tie” model of the Web [10]. 

In order to extract information from these levels, one may iteratively run 
the HITS algorithm, iteratively finding the hubs and authorities for the graph 
containing the union of level i and i -I- 1, for i = 0, . . . , to — 1, where to is the 
maximum number of levels. The internal HITS algorithm which runs on the 
adjacency matrix of a graph remains unchanged, but rather iterations of it are 
made according to external dependency data. The authors leave this for future 
work, speculating that the hubs of level i and the authorities of level i + 1 may 
be similar. 



4 Ongoing and Future Work 

This work has opened for us a number of questions with applications to digital 
libraries of formal mathematics. We hope to be able to answer deeper questions 
than the hubs, authorities, and communities discussed here, and to put some of 
our preliminary findings to practice and testing. We wish to extend these tech- 
niques to work on other representations of mathematical objects, and contribute 
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towards ongoing work in formal mathematical representation and presentation. 
Perhaps the strongest benefits may come from combining this graph-based ap- 
proach with others that reveal different kinds of information when it is available, 
such as integrating authority measures with pattern-matching based search when 
searching a library of math. 

Additionally, this work shows promise for an automated way of merging two 
collections of math from different proof assistants, by first matching up core 
basic definitions and then using dependency-graph analysis information to find 
similar proofs from two separate proof assistants. We may also use it to organize 
a single library, or to prepare a library for presentation by asking which objects 
are most influential and ought to be documented? Also, tools to visualize and 
interact with the digital collections surely aid us in analyzing the structures. 
Several theorem provers offer tree-like user interfaces and work in [7] presents 
methods for pruning the dependency graphs so that they are visually appealing. 
We are interested in how visualization in this context can aid a user searching a 
digital library of mathematics. 

Furthermore, the scale of the amount of mathematical data is surely not even 
comparable to the size of the web. The HITS methods are tractable for very large 
data sets. We may be able to take advantage of our relatively small graph sizes 
to get improved results. 



5 Conclusion 

We have shown applications of WWW search techniques to a new domain, 
namely, formal methods, along with presenting a modified stratified method 
for extracting information specific for formal math. This work is exploratory 
and the examples above attempt to demonstrate the potential of applying the 
HITS algorithm and related approaches to categorizing and searching formal 
mathematics. 

We presented two applications of HITS (1) finding Hubs and Authorities 
and (2) Communities, and also showed characteristics specific to the depth of 
proofs in the fdl library. We can conclude from these experiments that auto- 
mated means can be used to discern hub, authority, and community structure 
in at least one particular library of formal mathematics. The automated ex- 
traction of these kinds of relationships can be useful in ranking search results, 
for example, in the case of the authorities, or in organizing or merging related 
theorems, for example, based on the community structure. These experiments 
also demonstrate that logical dependencies alone can be informative in extract- 
ing these relationships. Also, what was less expected were findings of strongly 
characteristic breadth (link-degree) and depth (level) of the library. We cannot 
conclude whether these characteristics are specific to Nuprl, or common to the 
formal math domain, but we provide here a good basis for future comparison 
and discovery. 
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Abstract. In this paper, the current state of the System for Automated 
Deduction, SAD, is described briefly. The system may be considered 
as the modern vision of the Evidence Algorithm programme advanced 
by Academician V. Glushkov in early 1970s. V. Glushkov proposed to 
make investigation simultaneously into formalized languages for present- 
ing mathematical texts in the form most appropriate for a user, for- 
malization and evolutionary development of computer-made proof step, 
information environment having an influence on the evidence of a proof 
step, and man-assisted search for a proof. In this connection, SAD sup- 
ports a number of formal languages for representing and processing math- 
ematical knowledge along with the formal language ForTheL as their top 
representative, uses a sequent formalism developed for constructing an 
efficient technique of proof search within the signature of an initial the- 
ory, and gives a new way to organize the information environment for 
sharing mathematical knowledge among various computer services. The 
system SAD can be used to solve large variety of theorem proving prob- 
lems including: establishing of the deducibility of sequents in first-order 
classical logic, theorem proving in ForTheL-environment, verifying cor- 
rectness of self-contained ForTheL-texts, solving problems taken from 
the online library TPTP. A number of examples is given for illustrating 
the mathematical knowledge processing implemented in SAD. 



1 Introduction 

The evidential paradigm [14] of computer-aided “doing” mathematics is con- 
sidered as the core of the Evidence Algorithm programme (EA) advanced by 
V. Glushkov [11]. It is intended to provide a mathematician with rich and flexi- 
ble languages to formalize mathematical knowledge and with methods to prove 
a given proposition or to verify a given proof, steps of which should be “evi- 
dent” for a verificator. Thus, the notion of evidence of a proof step reflects the 
deductive power of proof search methods being applied. 

An implementation of the evidential paradigm must satisfy the following 
requirements: a formal language should be expressive enough to present mathe- 
matical knowledge in a natural “human-like” form; the evidence of proof steps 
should evolutionary develop in accordance with the progress in the field of au- 
tomated reasoning and other fields of computer mathematics; an information 
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environment should also evolve and influence the evidence of a proof step; inter- 
active technique should permit both a man-assisted searching and cooperation 
with external computer mathematical services, possibly, via Internet. 

The evidential paradigm is oriented to integration of numerical calculations, 
analytical transformations, and deduction. 

Numerical paradigm uses the methods and techniques of operation with 
numbers. For a wide variety of problems of applied mathematics, these methods 
give an approximate (or a precise) solution by constructing finite sequences of 
operations over finite sets of numbers. Usually, numerical methods start with 
the construction of a mathematical continual model. After this, this model is 
transformed into its discrete representation that permits to construct differ- 
ent algorithms of numerical calculation for a computer [2]. As an example, we 
can mention famous libraries of numerical algorithms implemented as Fortran 
batches. 

Analytical (symbolic) paradigm allows a computer to make complex 
symbolic transformations, to And analytical solution of (systems of) equations, to 
plot functions graphs, to build mathematical models of deterministic processes. 
Different computer algebra systems can serve as representatives of this paradigm. 

The following reasons gave rise to this approach: (i) existence of a big num- 
ber of labor-consuming tasks requiring routine analytical transformations before 
numeric calculations, (ii) reduction of efforts and a time spent in the case of 
solving a wide range of natural-scientific problems, (iii) compactness of repre- 
sentation and visual demonstrability of analytical solutions as compared with 
their numerical analogs. 

Deductive paradigm makes use of a declarative way of representation of 
mathematical knowledge. This means that all existent knowledge has the form 
of a formal text, and additional knowledge is obtained (deduced) from it with 
the help of different rules of reasoning (inference rules). 

The whole variety of systems that implement this paradigm can be roughly 
classified as follows: 

~ automated inference search systems (provers), such as Otter [171, Vampire 
[20], SPASS [25]; 

— interactive tactic-based proof assistants; the most well-known of them are 
Isabelle [18], PVS [19], and Coq [3]; 

— mathematical text processors: Mizar [22] and Theorema [6]. 

The evidential paradigm may be considered as a further development of the 
third type of the deductive paradigm in the direction of integration of deduc- 
tion with symbolic calculations that is oriented to a declarative approach using 
the mentioned-above language ForTheL [24] as a communication tool between 
different computer mathematical services. This is one of peculiarities that dis- 
tinguish Evidence Algorithm from Mizar, the system which has received a wide 
recognition all over the world. 

A number of reasons for the appearance of integration paradigm have arisen 
by now (cf. CALCULEMUS Initiative, http://www.calculemus.net/). First of 
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all, solving a really difficult problem requires simultaneously computations, ana- 
lytical transformations, and automated reasoning. Also, in spite of the fact that 
computer algebra systems are powerful and flexible tools, results of their work 
often require thorough logical checking because they can be invalid in general. 
On the other hand, although systems of automated reasoning can guarantee the 
validity of results, their efficiency remains low as compared to the one of com- 
puter algebra systems because they usually lack specific decision procedures and 
heuristics. 

Note that there exist two approaches to integrating computer mathemati- 
cal services: (i) integration on the stage of design, when the construction of a 
software system a priori presupposes use of both of its modules and different 
mathematical services as its “own parts” (Mizar, Theorema, and EA) and (ii) 
integration on the stage exploitations, that means “assembling a new system” 
from systems acceptable for solving a task under consideration and available 
at a time when the new system is “constructed” (here a great role is played 
by computer mathematical services that exchange data through network with 
the help of special protocols). The projects OMEGA [4], OpenMath [7], and 
MathWeb [26] can be mentioned as investigations in the last direction; note 
that they contain languages for specification and exchange of data that can 
be used not only for solving mathematical problems, but for many other pur- 
poses. 



2 System for Automated Deduction 

By now, the first approximation to the evidential paradigm is implemented in 
the System for Automated Deduction, SAD [23] . The system can be used online 
via Internet (http;/ /ea. unicyb.kiev.ua) for the following purposes: 

— parsing and translation of ForTheL-texts (some examples can be found on 
the web-site); 

— inference search in first-order classical logic on the basis of an original sequent 
calculus [8,15,1]; the user may supply his own problems or refer to the 
problems in TPTP problem library [21]; 

— theorem proving in the context of a self-contained ForTheL-text [9]; 

— verification of self-contained ForTheL-texts [16]. 

Any session of SAD consists of three main steps. First, SAD translates an 
input text (written in ForTheL or in a first order language) into its internal repre- 
sentation. In the translated text, the system selects a number of goals (statements 
to be proved) and, for each goal, determines the set of its logical predecessors 
(statements to be used in the proof). Finally, the system tries to deduce each 
goal from its predecessors. For this purpose, SAD may use its native first-order 
prover, as well as an external program. 

There exist six main modules in SAD: [ForTheL], [FOL], [TPTP], [Reason], 
[Explore], and [Moses]. Below we give a brief description of them. 
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Fig. 1. Architecture of SAD 



Modules [ForTheL] and [FOL], The modules [ForTheL] and [FOL] perform parsing 
of ForTheL-texts and first-order texts, respectively. Every of these modules con- 
verts an input text to a corresponding internal representation. This conversion 
preserves the structure of an initial text and translates phrases into an ordered 
set of first-order formulas. For input texts written in the first-order language, 
translation is not needed, so [FOL] just eliminates “syntactical sugar” . 

Module [TPTP]. Recently, we have added a new interface module that connects 
SAD with the wide-known TPTP library that contains several thousands of 
logical problems for automated proving systems [21]. The system SAD downloads 
problems and axioms directly from the web-site of TPTP (one can also supply 
his own problem in the syntax of TPTP), and [TPTP] translates a task into its 
internal representation. 

Module [Reason]. This module runs a verification cycle, formulates verification 
tasks, and tries to solve them using its own reasoning capabilities together with 
the prover of SAD. In particular, [Reason] processes proofs by case analysis and 
by induction reasoning, simplifies a goal taking into account assumptions and 
affirmation written in the text, splits a complex goal to a number of simpler 
subgoals, and so on. 

The role of the module [Reason] will be demonstrated below on an example 
taken from a real verification session. 

Module [Explore]. This module serves for purely technical purposes: it acts as a 
mediator between SAD and external theorem provers that can be used instead 
of (or together with) the own prover of SAD. 
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Module [Moses]. This module is the prover of SAD and is intended for inference 
search. It is implemented on the base of the sequent calculus GD (see below). 

The prover looks through the search space using bounded depth first search 
with iterative deepening and backtracking. In order to increase the efficiency of 
inference search, [Moses] uses special constraints and folding-up technique [13]. 
Also, solutions of accumulated systems of equations are found only in reasonable 
cases. A special heuristics is adopted for definition application. 

In order to provide SAD with equality handling capabilities, [Moses] imple- 
ments a certain variation of Brand’s modification method [5] . 

Note that since the calculus GD does not change initial premises, the prover 
performs operations with a tree of literal goals instead of a tree of sequents. This 
drastically reduces needs in computational resources. 

Due to the absence of preliminary skolemization, the prover of SAD is capable 
to use a relevant solver for solving equation systems. The submodule of [Moses] 
responsible for equation handling acts as a mediator between the prover and 
external solvers. It checks a substitution found by such a way for admissibility 
and builds additional equations if necessary. The procedure computing the most 
general unifier is used as a default equation solver. 



3 Linguistic Tools of SAD 

The language ForTheL (Formal Theory Language) [24] is a language with for- 
mally defined syntax and semantics. It is intended for representation of math- 
ematical texts including axioms, definitions, theorems and proofs. ForTheL is 
designed to be close to the natural language of real-life mathematical publi- 
cations issued by human mathematicians. There are two reasons to pursue a 
verbose “natural” style instead of using the unified notation of some traditional 
logical language. 

The first reason is to provide our framework with a user-friendly interface. A 
text composed with correct English sentences will hopefully more readable and 
easier to write than a collection of formulas built with quantifiers, parentheses, 
lambdas, junctors, and so on. 

Second, a natural human text usually contains a certain useful information 
which lies beyond the scope of classical logic. For example, we distinguish def- 
initions from ordinary axioms, theorems from intermediate statements inside a 
proof, and we tend to use them in different ways when reading a text. In a nat- 
ural sentence, we meet nouns, which denote classes of entities; adjectives and 
verbs, which act as attributes and restrict classes; adjectives and verbs, which 
act as predicates and may relate different entities. However, where human lan- 
guage makes distinctions, the language of mathematical logic unifies: subjects, 
objects, attributes, predicates all become predicate symbols; axioms, theorems, 
definitions, ordinary statements all become formulas. 

Our intention is to preserve these distinctions in formalization. We investi- 
gate how a human mathematician treats definitions as compared with axioms 
or lemmas, class-nouns as compared with adjectives, proofs by case analysis as 
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compared with proofs following other schemes, and so on. Basing on these obser- 
vations, we improve reasoning capabilities of a machine, we implement heuris- 
tic routines directing proof search or reducing a search space with the help 
of “non-logical” knowledge extracted from a formal, yet “natural-like” input 
text. 

From the syntactical point of view, any ForTheL-text is a sequence of sections. 
Each section contains phrases and/or sections of lower levels. Top-level sections 
(such as theorems, axioms, definitions) play in ForTheL-texts the same role they 
do in usual mathematical texts. Typical sections of lower level are proofs, proof 
blocks, and proof cases. The phrases of ForTheL are either assumptions (then 
they begin with “let” or “assume”) or affirmations. 

The grammar of ForTheL-phrases imitates the grammar of English sentences. 
Phrases are built using nouns, which denote notions (classes) or functions, verbs 
and adjectives, which denote predicates, and prepositions and conjunctions, 
which define the logical meaning of a complex sentence. For example, “Every 
closed subset of every compact set is compact.” is a simple ForTheL- 
affirmation. One can introduce a concise symbolic notation for predicates and 
functions and write statements in the form of usual first-order formulas. 

The logical connectives along with some predicates and notions are prede- 
fined in ForTheL. All other syntactical units must be introduced explicitly. We 
use special introductors to declare new lexical primitives. For example, the in- 
troductor “ [a divisor/divisors of x] ” extends the current vocabulary with 
a new noun denoting an unary notion (equivalent forms of the same word 
may be listed with slashes). Also, one may introduce a new primitive as a 
synonim: “ [x divides/divide y 0 x is a divisor of y]” introduces a new 
verb. 

An affirmation in a text, e.g. the statement of a theorem, can be provided 
with a proof section. A ForTheL-proof is a sequence of assumptions, affirmations 
(which may have their own proofs), and proof cases. 

The simple example of a self-contained ForTheL-text is given below: 

[a set/sets] [an element/elements of x] 

[x is in/from y @ x is an element of y] 

[a subset/subsets of x] [x is empty] 

Definition Def Subset. Let S be a set. 

A subset of S is a set X such that every element of X is in S . 

Definition DefEmpty. Let S be a set. 

S is empty iff S has no elements. 

Axiom ExEmpty. There exists an empty set. 

Theorem. Let S be a set. 

S is a subset of every set iff S is empty. 



This text will be translated into the following first-order representation. 
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Definition Def Subset, forall S (aSet(S) implies 
(forall x_l (aSubsetOf (x_l , S) iff (aSet(x_l) and forall x_2 
(aElementOf (x_2,x_l) implies aElementOf (x_2 , S) ) ) ) ) ) . 

Definition DefEmpty. forall S (aSet(S) implies 
(isEmpty(S) iff not exists x_l aElementOf (x_l ,S) )) . 

Axiom ExEmpty. exists x_l (aSet(x_l) and isEmpty (x_l) ) . 

Theorem, assume aSet(S). 

(forall x_2 (aSet(x_2) implies aSubsetOf (S ,x_2) ) ) iff isEmpty (S) . 



4 Theorem Proving in SAD 

Since the internal representation of an input problem is based on a kind of 
the first-order language, SAD uses its prover for inference search in first-order 
classical logic. It was mentioned above that a special sequent formalism was 
developed and implemented in [Moses], the prover of SAD. In order to make this 
paper self-contained, we give a brief description of a certain modification GD’ of 
the calculus GD introduced in [15] and used in [Moses]. 

Admissible Substitutions. Let D be a set of closed formulas such that no two 
distinct quantifiers in F bind the same variable. Let Vr stand for the set of 
indexed variables {^v \ v occurs in D, fc G IN }. The expression will denote 
the formula F with each variable v replaced with an indexed variable ^v. 

We write F [C?'*"] {F [G“ J ) to denote a formula F with a positive (respectively, 
negative) occurrence of a subformula G. A variable G Vr is said to be unknown 
in r if for some formula P G F, P[(Vr;F)+J or Gorrespondingly, x 

is said to be fixed in F if for some P G F*, P[(VwT’)“J or P[(3vT’)+J . Obviously, 
each variable in Vr is either unknown or fixed. 

The set F induces a partial ordering ^r on Vr as follows: ~<r '^w if and 

only if (a) k = m, and (b) a quantifier on w occurs in the scope of a quantifier on 
u (that is, some formula F G T is of the form {... Qiu {... Q 2 W 

Given a substitution a, we define another partial ordering <C^ on Vr as 
follows: <Cr if and only if is unknown in F and is fixed in P and 

occurs in ^ua. 

A substitution cr is said to be admissible in F if and only if (a) a substitutes 
for unknown variables only (that is, xa yf x implies that x is unknown in F), 
and (b) the transitive closure of Ar U is a partial ordering. 

A substitution tt is called pasting in F if and only if (a) tt just changes indexes 
of indexed variables (that is, xtt x implies that x is of the form and xn is 
of the form ™r), and (b) if Ar and ^vtt = then 

Inference Rules. The main object of the calculus GD’ is an a-sequent, which is 
an expression of the form [yl] F ^ G, where yl is a list of literals, called framed 
literals, F is a list of formulas, called premises, and G is a goal formula. In our 
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setting, A and G contain indexed variables only, and F does not contain indexed 
variables at all. 

When a proof of an initial a-sequent is searched in GD’, an inference tree 
is constructed. At the beginning of a search process the tree consists of the 
initial a-sequent. The tree grows from top to bottom, with the subsequent nodes 
generated in accordance with the inference rules of GD’. 

At some moments of inference, branches in the tree may be terminated', a leaf 
node containing an equation of the form {Li « L 2 ) (where Ai, L 2 are literals) is 
added to such a branch and no more expansions are possible on it. 

Below, denotes the negation of F with the negation sign moved inside F-. 

(V X P)^ = 3x ~^P (P V Q)^ = A (P D Q)^ = P A 

(3xPr = Wx^p {p aqy = ^py {^py = p a^ = ^a 

The expression *F stands for ^F where k is a fresh index with respect to the 
whole inference tree. In the following inference rules. A, B are unifiable atoms 
and L, M are unifiable literals. 

Goal- Splitting Rules (GS): 
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Auxiliary -Goal Rule (AG): 



Termination-by- Framed- Literal Rule (TF): 



Termination-hy-Premise Rule (TP): 
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The following goal-drivenness constraint is applied to the inferences in GD’. 
Whenever an AG-rule is applied and the atom A (possibly, negated) goes to the 




244 A. Lyaletski et al. 



end of the list of framed literals, the corresponding occurrence of B in * must 
be fixed and remembered. We require that the subsequent applications of goal- 
splitting rules never remove that occurrence of B from the proof. In other words, 
that occurrence of B must form a literal goal after a number of splittings. Then, 
we require the branch containing this goal to be terminated by an application 
of TF-rule, with the equation {A « B) in the leaf. 



Proof Trees. Let us consider an inference tree T where every branch is termi- 
nated. Let r denote the set of premises in the initial a-sequent. Let E denote 
the overall system of substitutional equations in the leaves of the tree. 

The inference tree T is considered to be a proof tree whenever there exist 
substitutions cr and tt such that: (a) cr is admissible in F, (b) tt is pasting in T, 
and (c) cr o 7T is a solution for E (that is, Eira is a set of identities). 

The initial a-sequent of a proof tree is called deducible in GD’. 

Theorem 1 (Soundness and Completeness of GD’). Let F be a eonsistent 
set of formulas and G be a formula. The sequent F ^ G is deducible in Gentzen’s 
calculus LK [10] if and only if the a-sequent [ ] T, —‘G °G is deducible in the 
calculus GD’. 



Note that equation solving is separated from application of inference rules. 
Substitutional equations may be accumulated and be sent to a solver in arbitrary 
moment of search. This property of GD’ allows to organize a flexible proof search 
procedure. We underline that the calculus GD’ does not rely upon preliminary 
skolemization, so that equations are formulated in the initial signature and a 
theory-specific equation solver may be used. 

Let us demonstrate the deductive technique of SAD on a simple propositional 
problem. Assume that we want to prove the sequent AV {B \/ A) ^ AV B. Let 
F = {A\/ {B \/ A), ^{A\/ B)}. A GD ’-inference used to prove the a-sequent 
[ ] T ^ Ay B is shown below: 



F ^^A 
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Note that in any GD ’-inference the premises are the same in each a-sequent. 
Moreover, the list of framed literals in a given node is exactly the list of the 
complements of literal goals above that node. So, we can present the proof tree 
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given above in a quite abbreviated form, as the tree of literal goals. In the 
following inference, applications of the auxiliary-goal rule are joined with the 
subsequent applications of goal-splitting rules in a single inference step, and 
termination by a framed literal becomes termination by a contradiction in a 
branch: 



[ ] A V (B V A),^{A V B) ^ AV B 
A 






lA « -.A) 
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(B^B) 



{AG + GS) 
(TF) 
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Fetching Problems from the TPTP Library. As we said above, the system SAD 
may refer to the TPTP problem library and downloads problems and axiom sets 
directly from the web-site of TPTP, so that it is sufficient to give the identifier of 
the problem to SAD in a corresponding mode. For example, given SETOOl-1 .p, 
SAD downloads first the text of the problem (comments are erased): 

includeC ’ Axioms/SETOOl-0 . ax’ ) . 

input_clause(b_equals_bb, hypothesis , 

[++equal_sets(b,bb)] ) . 

input _clause (element _of_b , hypothesis , 

[++member (element_of _b,b)] ) . 

input_clause(prove_element_of _bb, conjecture , 

[ — member (element_of_b,bb)] ) . 

parses it, and then downloads the needed axiom set. The resulting text is 
transformed into an appropriate a-sequent and the inference search procedure 
is started. The following information will be displayed when the session 
finishes: 



[Reason] inference search successful 
[Main] session finished in 00:00.01 

[Main] 00:00.00 in [TPTP] - 00:00.00 in [Reason] - 00:00.01 in [Moses] 



Theorem Proving in ForTheL-environment. Let us consider again the ForTheL- 
text about empty sets given above. The following text demonstrates the output 
of SAD when proving the last theorem. The proposition is “evident” for SAD 
and the proof is found in less than a second. 

The proof of the proposition has the form of a tree of literals, in a similar 
fashion to the proof tree given above. This inference can be transformed in the 
usual Gentzen-type sequent proof or in the Gentzen’s natural inference. 
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Proof tree nodes: 17, depth: 5. 

Proved in 10 msec (steps: 208, nodes: 614, depth bound: 4). 



Root : 

isEmpty (S#9 [1] ) 

-isEmpty (S#9 [1] ) 

-aElementOf (x_l#7[2] (S#9 [1] ) ,S#9 [1] ) 
aElementOf (x_l#7 [2] (S#9 [1] ) , S#9 [1] ) 
aSubsetOf (S#9[l] ,x_l#8[5] ) 

-aSubsetOf (S#9[4] ,x_l#8[5]) 

-isEmpty (S#9 [4] ) 
aSet (x_l#8 [5] ) 

-aSet(x_l#8 [5] ) 

-aElementOf (x_l#7 [2] (S#9 [1] ) ,x_l#8 [5] ) 
aElementOf (x_l#7 [2] (S#9 [1] ) ,x_l#8 [5] ) 
isEmpty (x_l#8 [5] ) 

-isEmpty (x_l#8 [7] ) 
aSet (x_l#8 [5] ) 
aSet (x_l#8 [5] ) 
aSet(S#9[l]) 

-aSet(S#9 [8] ) 

-aSet(x_2#a[l] ) 
aSet(x_2#a[l] ) 

-aSubsetOf (S#9 [10] ,x_2#a[l]) 
aSubsetOf (S#9 [10] ,x_2#a[10]) 
isEmpty (S#9 [10] ) 

-aElementOf (x_2#4 [9] (x_2#a[l] ,S#9 [10] ) , S#9 [10] ) 
aElementOf (x_2#4 [9] (x_2#a[l] , S#9 [10] ) ,S#9 [10] ) 
isEmpty (S#9 [10] ) 
aSet(S#9[10] ) 
aSet(S#9[10]) 

5 Text Verification in SAD 

This section is devoted to the verification procedure of SAD and to the peculiar- 
ities of formalization style. We consider a real mathematical problem: Ramsey’s 
theorem (both finite and infinite versions) as it is presented in the beginning of 
Graham’s introductory book [12]: 

Infinite Ramsey’s Theorem. For all k,r G oj and any r-coloring ^ ^ [r] of 

the k-element subsets of uj, there is always an infinite subset S C oj with all its 
k-element subsets having the same color. 

A set hypergraph H = H{V, E) denotes a set V together with a family E of 
subsets ofV in presupposition that every of them contains at least two elements. 
The chromatic number of H, denoted by x{H), is defined to be the least integer 
r such that there is an r-coloring of V so that no edge in E is monochromatic. 

Compactness Theorem. If x(if) > t and all edges of H are finite then there is a 
finite subhypergraph G of H with x(G) > t. 
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Finite Ramsey’s Theorem. For all k,l,r € to there exists N € to such that ifn^N 
and ^ : [ ^ ] — > [r] is any r-coloring of the k-subsets of [n] then some l-subset of 
[n] has all its k-subsets with the same color. 

These propositions and their proofs were formalized and automatically veri- 
fied in SAD. As an experiment of proving systems cooperation, the automated 
theorem prover SPASS [25] was used as the external prover to support verifica- 
tion and showed excellent results. The whole ForTheL-text consists of 490 lines 
of which 200 are used for preliminary facts: common elements of set and number 
theory, definitions and properties of functions and predicates used in the text. 
The rest 290 lines contain the formalization of the above text together with 
three proofs. Note that the above text together with two proofs (the proof of Fi- 
nite Ramsey’s Theorem is not given) takes approximately 130 lines in Graham’s 
book. So, we can consider ForTheL (and the whole system SAD) as a rather 
economical tool for formalization of texts. 

The given-above definitions and propositions are rewritten in ForTheL as 
follows (we replace some ASCII-notation with more readable notation of TgX) . 

Theorem Ramseyinf. Let T be a finite set. 

For every (fc G to) and every countable (S' C to) and every (c : [S/k] T) 
there exists an element u of T and a countable ACS such that 
for every (Q G [X/k]) c{Q) = u. 

Definition DefChromC. 

Let H he a hypergraph and L : Ver H ^ T for some finite set T. 

L is chromatic for H iff H has no edge that is monochromatic in H wrt L. 

Definition DefChromT. 

Let H he a hypergraph and T be a finite set. 

T is chromatic for H iff there exists L : Ver H ^ T chromatic for H. 

Theorem Compactness. 

Assume H is a hypergraph and Ver H = to. 

Assume every edge of H is finite. 

Let T be a finite set chromatic for every finite subgraph of H . 

Then T is chromatic for H. 

Theorem RamseyFin. Let T be a finite set. Let k,l be numbers. 

Then there exists a number n such that for every (c : [[n]/A:] ^ T) 
there exists an element u of T and an element A of [[n]/?] 
such that for every {Q G [X/k]) c{Q) = u. 

We don’t give here the whole ForTheL-text. Instead, we will consider a frag- 
ment from the proof of the Infinite Ramsey’s Theorem that illustrates well the 
peculiarities of text verification in SAD. 

The Infinite Ramsey’s Theorem is proved by induction on k. In the proof 
of the induction step, we build a number of objects (sequences, functions, and 
sets) and prove their properties. The most important construction in our proof is 
a recursively defined sequence of subsets of to. This sequence is decreasing, 
that is Ai_|_i C cdr Ni = Ai\{minAi}. We want to prove a simple yet useful 
consequence of this fact: 
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For every {i,j G uj) ii j ^ i then N{i) C N{j). 

proof by induction. 

Let i,j be numbers so that j ^ i. 

Let / be a number so that i = succ I. 

Case i ^ j. Obvious. 

Case j < I. 

Then N{I) C N{j) (by IH). 

cdr (N{I)) C N{I) (by DefDiff). 

N{i) C N{j) (by SubTrans). 

end. 

end. 

The main affirmation is proved by natural induction. The systems assumes by 
default that the induction is held by the topmost universally quantified variable 
in the goal, that is, by i. Also, you can mention the induction term explicitly 
(“proof by induction on i+j.”). 

The verificator ([Reason]) checks that the first assumption in the proof section 
introduces the required variables and corresponds to the conditions in the goal. 
Then the appropriate induction hypothesis IH(t) is formulated: 

\/x ,y G u) {x < i D {y X D N (x) C N{y))) 

and is added to the logical context of the rest of the proof. 

In our proof, the base case (z = 0) is obvious, since N{0) = oj by defini- 
tion. Therefore, we simply omit it and consider the induction step. We assume 
existence of the predecessor of i and prove the current goal N{i) C N{j) by 
case analysis. Note that the goal was simplified in accordance with the first 
assumption. 

When a sequence of proof cases is considered, the system checks that the case 
analysis is complete, i.e. the corresponding disjunction is valid. In our proof, the 
disjunction is succ x ^ y V y ^ a; and it is easily verified. Then the reasoner tries 
to prove the current goal for each case respectively. Note the reference to the 
induction hypothesis made in the second case section. 



6 Conclusion 

This paper is devoted to the description of mathematical texts processing in 
the framework of evidential paradigm having now the form of the implemented 
system SAD that is intended for different complex ways of mathematical texts 
processing, mainly, automated theorem proving and checking formal mathemat- 
ical texts. In this connection, the system SAD exploits simultaneously a formal 
language for presenting mathematical texts (including theorems, their proofs, 
and necessary environment) in the form most appropriate for a user, as well 
as a formal notion of computer-made proof step based on sequent formalism of 
first-order logic. Mathematical text processing in SAD consists of three main 
steps: firstly, writing a text under consideration in a special formal language. 
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secondly, translation of the written text into a text in the form of a set of special 
first-order formulas, and thirdly, proving/checking the special text with the help 
of sequent- type deductive tools. 

Finally note that systems that constructed on the basis of the evidential 
paradigm (in particular, SAD) can be useful in many industrial fields such as 
computer-aided processing of computer knowledge, automated reasoning, check- 
ing soft and hardware, logical inference search taking into account constraints, 
distributed learning, e-learning, data mining from mathematical papers, con- 
struction knowledge bases for formal theories. 
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Abstract. Mathematical tools such as computer algebra systems and 
interactive and automated theorem provers are complex systems and 
can perform difficult computations. Typically, such tools are used by a 
(small) group of particularly trained and skilled users to assist in math- 
ematical problem solving. They can also be used as back-engines for 
interactive exercises in learning environments. This, however, suggests 
the adaptation of the choice of functionalities of the tool to the learner. 
This paper addresses the adaptive usage of the proof planner Multi for 
the learning environment ActiveMath. The proof planner is a back- 
engine for interactive proof exercises. We identify different dimensions in 
which the usage of such a service system can be adapted and investigate 
the architecture realizing the adaptive access to Multi. 



1 Motivation 

So far, the main application of mathematical systems such as computer algebra 
systems and theorem provers has been for assisting trained and skilled users. This 
user group determines many design decisions. For instance, interactive theorem 
proving systems try to support the proof construction by restricting choices to 
valid proof steps, they suggest applicable lemmas, or they produce a subproof 
automatically. These functionalities are useful, e.g., for interactively verifying a 
program and reduce the workload of the proof expert. 

Another application of a mathematical system may be as a cognitive tool 
in a learning environment for which the user group consists of learners rather 
than proof experts. Empirical evidence indicates that active, exploratory learn- 
ing helps to construct knowledge and skills in a learner’s mind. In particular, 
empirical studies [13] suggest that student’s deficiencies in their mathematical 
competence with respect to understanding and generating proofs are connected 
with the shortcoming of student’s self-guided explorative learning opportunities 
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and the lack of (self-)explanations during problem solving. Such an explorative 
learning can be supported by tools. For this reason, the web-based adaptive 
learning environment for mathematics, ActiveMath, integrates problem solv- 
ing systems as back-engines for interactive exercising. 

In an educational context the original features of typical mathematical sys- 
tems are not sufficient. Rather, an educational context requires additional fea- 
tures for effective learning such as 

~ adaptivity to the learner, 

— feedback on the learners activities, 

— possibility to make mistakes. 

In order to realize those features and to adapt to the student’s context, 
goals, needs, capabilities, preferences, and previous activities, the setting and 
the user interface of tool-supported interactive exercising needs to be adaptable 
to the learner in a pedagogically and cognitively sound way. Thus, for interactive 
exercising the back-engine has to be extended so that it can process information 
from ActiveMath’s student model and pedagogical knowledge base. Similarly, 
information about the learner’s misconceptions or performance in an exercise 
should be returned to the student model. 

In this paper, we describe a first adaptive integration of the proof planner 
Multi with the learning environment ActiveMath. In particular, we discuss 
the different dimensions along which the usage of the proof planner Multi can 
be adapted. Mostly, we describe personalization dimensions although the same 
setting can also be used for adaptation of accessibility and customization. We 
investigate the necessary extensions of Multi and the architecture realizing the 
adaptive access to Multi. 

The paper is structured as follows. We start with preliminaries about Ac- 
tiveMath and the proof planner Multi, since these might not be known to 
the gentle reader. Afterwards, we identify adaptivity dimensions of Multi for 
interactive proof exercises and present the architecture for the adaptive access of 
Multi. In section 5 we describe the realization of some directions of the adaptiv- 
ity. Section 6 discusses potential extensions of the current approach and future 
work. We conclude with a discussion of results and related work. 



2 Preliminaries 

Empirical results indicate that instruction with proof planning methods, which 
explicitly encode mathematical steps, can be a learning approach that is superior 
to the traditional teaching of mathematical proof [7]. This motivates to use proof 
planning for maths education and the connection of the proof planner Multi 
with the user-adaptive learning environment ActiveMath. 

The following is only a brief introduction to ActiveMath and Multi. For 
more details on proof planning and Multi the interested reader is referred to [9, 
8]. For more details on ActiveMath see [6]. 
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2.1 ActiveMath, its Student Model and Pedagogical Knowledge 

ActiveMath is a web-based, user-adaptive learning environment for mathemat- 
ics. The learner can choose learning goals to achieve a scenario. ActiveMath 
generates learning material user-adaptively, i.e., dependent on the learner’s goals, 
learning scenarios, preferences, and knowledge. A course generator determines 
the concepts that the student needs to learn for a goal chosen by the learner and 
selects the appropriate instructional items (explanations, definitions, examples, 
exercises, etc). According to pedagogical knowledge, this selection also includes 
the number, type, and difficulty of exercises and examples, as well as the in- 
teractivity setting of exercises (e.g., what is requested from the learner, which 
functionalities can be used). It assembles the instructional items in a sequence 
which is suggested by the scenario chosen and the pedagogical strategy following 
it. The adaptivity is based on a student model that includes 

— the student’s mastery level of concepts and skills 

— the history of the learner’s actions (e.g., time spent per item) 

— her preferences (e.g., preferred language), the chosen learning scenario, and 
the learning goals as input through a questionnaire. 

The student model is updated based on results of the learning activities 
such as reading and problem solving. That is, the student’s exercise 
performance is evaluated and the evaluation is passed to the student model 
for updating it. 



2.2 Proof Planning 

Originally, the goal of the research on proof planning [2] was to prove mathemat- 
ical theorems automatically. The knowledge-based approach in Multi employs 
mathematical strategies, methods, and computations for this purpose. It guides 
the search by heuristics known from mathematical problem solving in specific 
mathematical areas. 

Proof planning starts with a goal that represents the conjecture to be proved 
and with proof assumptions. It continues by applying a method (such as proof by 
induction) for which the application conditions are satisfied and this generates 
new assumptions or reduces a goal to (possibly trivial) subgoals. This process 
goes on until no goal is left. The resulting sequence of instantiated methods 
constitutes a solution proof plan. 

Generally, proof construction may require to construct a mathematical ob- 
ject, i.e., to instantiate existentially quantified variables by witness terms. In 
proof planning meta-variables are used as place holders for such objects un- 
til enough information is collected to instantiate the meta-variable. A domain- 
specific constraint solver can help to construct mathematical objects that are 
elements of a specific domain. During the proof planning process the constraint 
solver checks the (in)consistency of constraints on met a- variables and collects 
consistent constraints in a constraint store. Then, it computes instantiations for 
the meta-variables that satisfy the collected constraints [10]. 
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To structure the repertoire of proof planning methods and make the proof 
planning process more hierarchical, strategies have been introduced. One of the 
types of proof planning strategies is specified by a set of methods and search 
heuristics. Different proof planning strategies can correspond to and implement 
different proof ideas. In the automatic mode, the proof planner searches for ap- 
plicable strategies (including object construction and backtracking) or methods 
in each intermediate state until it reaches a solution proof plan. Mathematics- 
oriented heuristics guide this search. 

For new applications. Multi has been extended with an interactive mode. 
In interactive proof planning, the user searches and makes the decisions, which 
can include the choice of strategies, of methods, and the instantiation of meta- 
variables. 



3 Adaptation to the User 

The proof planning service can be requested for proof examples that are (dynam- 
ically) demonstrated and for interactive exercises in which Multi can be used 
as a back-engine. In these applications, the Multi service can be adapted ac- 
cording to the learning scenario, the goals, the preferences, and the prerequisite 
knowledge of the learner. In the following, we shall discuss several adaptation 
dimensions together with cognitive and other variables of the learner that may 
affect the adaptation. 

3.1 Proof Planning Scenarios 

The first dimension of adaptation of the Multi service is the exercise scenario. 
There are several types of proof exercises, e.g., those in which the student can 
interactively apply certain proof planning methods, freely explore, or in which 
the learner sketches proof steps and Multi checks the student’s steps. Accord- 
ingly, we identified several pedagogically motivated proof scenarios. They differ 
with respect to the overall learning goal and the employed service functionalities. 
The selection of a scenario is performed by ActiveMath, which requests the 
Multi service. 

Replay and Presentation of a Proof Plan. Completed proof plans (or parts 
of proof plans) are presented to the learner. The proof plan can be presented 
at once or stepwise. This scenario targets an understanding of the effects 
of the application of individual methods, how several method applications 
combine to a proof plan or provide a basis for self-explaining a proof. The 
learner’s activities in this scenario are mainly restricted to browsing the pre- 
sentation of the proof plan, of methods and of the constraint store as well 
as replaying a proof plan step-by-step or hierarchically. 

Interactive Proof Planning. The learner constructs a proof plan for a given 
problem or has to complete a given proof plan with gaps by selecting and 
applying methods from a pre-defined set of methods or strategies as well as 
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by instantiating meta- variables. This scenario targets the ‘technical’ mastery 
of proof steps and proof heuristics. Moreover, the learner can realize the 
effects of instantiating a meta-variable and receive support for constructing 
mathematical objects that instantiate a met a- variable. As we shall see later 
(see section 5), the learner’s main activities are the selection of the next 
step (and its details) as well as the specification of met a- variables. Other 
possibilities are browsing the current proof plan and requesting additional 
information, e.g., from the constraint store. 

Island Planning. The learner constructs a proof sketch for a problem. This 
scenario targets the understanding of the proof process without details. The 
student is supposed to find a proof idea and to provide a structure of the 
proof by specifying important intermediate goals in a proof plan, so-called 
proof islands. The main user interactions in this scenario are adding proof 
islands as well as links between the islands, the theorem and the assumptions 
that describe which proof nodes depend from which other proof nodes. In 
addition, the current island plan can be browsed and additional information 
can be requested. 

Free Exploration. The learner obtains full access to the proof planner. She 
has to state the problem and initiate the proof process. Moreover, she can 
freely access different kinds of proof manipulations (application of strategies, 
of methods, of tools, instantiation of meta- variables) . This scenario is only 
sensible for advanced learners. It targets exploration and discovery learning. 

Meta-cognitive Framework. Polya suggested a framework for teaching mathe- 
matical problem [11]. He formulates a set of heuristics cast in form of brief 
questions and prompts within a frame of four problem solving stages: (1) Un- 
derstand the problem (2) Devise a plan (3) Carry out the plan (4) Look back 
at the solution. Questions and prompts for (2) are, for instance: do you know a 
related problem? did you use all the data? Following Polya’s ideas, each of the 
above scenarios can be enriched with meta-cognitive scaffolding in form of con- 
text sensitive subtitles, questions and prompts. This targets a structured proof 
process with separated phases. 

3.2 Other Adaptation Dimensions 

Other important adaptation dimensions control the possible or preferred prob- 
lem solving strategies, the range of method choices, domains from which 
mathematical objects can be drawn etc. For instance, an exercise about the 
limit of a sequence can be solved by the application of limit theorems proved 
before or by using only the definition of the limit. The choice of such a proof 
idea depends on the learner’s capabilities and on the pedagogical strategy. 

In the interactive proof planning scenario Multi provides suggestions of 
method applications and meta-variable instantiations to the learner (see sec- 
tion 5). In this scenario an adaptation decision is whether all the suggestions 
have to be correct or not. This is important, since errors can be an important 
source of learning. As opposed to a learning context faulty suggestions are 
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not appropriate for problem solving assistance. For learning, however, it might 
not be the best idea to make only correct suggestions because then the student 
might just click on any suggestion rather than learn anything. 

For instance, when the student has to prove the limit of a sequence by apply- 
ing theorems and she is already familiar with the theorems, then it may be too 
boring and not interesting to suggest only applicable theorems. Again, the deci- 
sion on when to make which faulty suggestion depends on the student’s situation 
and on her capabilities and on the pedagogical strategy. 

Further dimensions for adaptation are the user interface appearance and 
the feedback. 

Note that, so far, we focused on the realization of the adaptive application of 
the interactive proof planning scenario. A description of the adaptivity realized 
so far is given in section 5. An adaptive graphical user interface and adaptive 
feedback delivery are not realized so far. 

3.3 Some Variables to Adapt to 

Adaptation may depend on the learner’s expertise. For instance, a student who 
is a novice in proving will have more difficulties to choose between many methods 
and therefore a large set of alternative methods to choose from should be avoided 
because it increases the likelihood of guessing instead of learning and reasoning. 

Adaptation may also depend on the learner’s activity history. For instance, it 
seems not to be advisable to make suggestions for a method, in case the student 
has not been able to apply that method for several times recently. 

Many dimensions of adaptation do not only depend on the learner’s aptitudes 
but also on the chosen pedagogical strategy. For instance, the decision when to 
allow for faulty suggestions will depend not only on the student’s situation and 
on her capabilities but also on the pedagogical strategy. 



4 Architecture 

For all those adaptations of the proof planning service the actual proof planner 
has to be extended by a scenario management and by mediators as described 
below. That is, the service encapsulates mediators which provide a (Web-) com- 
munication interface and compute some of the adaptations. The communication 
relies on XML-RPC protocols^ and the Omdoc language [3] and is not further 
considered here. 

Figure 1 depicts the architecture of the proof planning service and its com- 
munication with the learning environment ActiveMath including its student 
model and pedagogical knowledge. 

The architecture separates different functionalities and different kinds of 
knowledge. This modularization helps to maintain and update modules and to 
re-use components. As a side effect, the GUI becomes more independent and 
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Fig. 1. The architecture of the Multi service and its communication with Active- 
Math and the GUI 



adaptable. This part of the architecture (i.e., GUI and GUI-mediator) is, how- 
ever, not yet implemented. 

Scenario-Manager. The Scenario-Manager provides a communication shell 
around Multi and realizes the different proof scenarios, which use particular 
proof storage and proof manipulation functionalities of the proof planner. The 
scenario for interactive proof planning employs - among others - the following 
functionalities: 

— compute method application and meta- variable instantiation suggestions for 
the learner, 

~ check whether method applications and meta-variable instantiations issued 
by the learner are applicable, 

— apply applicable steps, 

— check whether proof planner can automatically complete the current proof 
plan, 

— analyze the differences between the current proof plan fragment and a solu- 
tion proof plan completed by the proof planner. 
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Relevant for island planning are, in particular, the functionalities: 

— apply the island nodes and links specified by the user as abstract steps in 
the proof plan under construction, 

— try to verify islands with automated proof planning or other tool support 
available in Multi (e.g., with integrated computer algebra systems or auto- 
mated theorem provers). 

The Exercise Composer and the Evaluator provide interfaces for the commu- 
nication between ActiveMath and the Scenario-Manager. 

Exercise Composer. When ActiveMath requests a proof planning session, then 
the Exercise Composer computes the input for the parameters of the Scenario- 
Manager and the scenario. For instance, when the interactive proof planning 
scenario is requested, then the Exercise Composer determines the range and 
restriction of suggestions that the scenario component computes and provides 
to the learner. The Exercise Composer uses student model information for this 
computation. 

Evaluator. At the end of an exercise the Evaluator receives an account on how 
complete and sound the learner solved the exercise. From this account the Eval- 
uator computes information, which summarizes the learner’s actions. The Eval- 
uator passes this information to the persistent student model of ActiveMath. 

GUI. The GUI is an independent component. It will be an applet or even a 
standalone GUI (not integrated into ActiveMath). 

GUI- Mediator. The GUI-mediator is needed to adapt the presentation and feed- 
back to the learner’s needs and to configure the GUI. The GUI-Mediator realizes 
the communication between the GUI and the other components of the proof 
planning service. For each scenario, it interprets the meaning of GUI-objects 
and their manipulation and passes the interpretation of manipulations to the 
components of the proof planning service. Vice versa it translates information 
from the components to the GUI. This is an adaptive translation depending on 
information from the student model. Its main functionalities are: 

— invoke and configure the GUI for a scenario and the individual learner. Adapt 
the GUI to user characteristics such as preferred language and to the pecu- 
liarities of the different scenarios (different scenarios require different user 
activities and different GUI-objects). 

— interpret user interactions with the GUI and pass interpreted information to 
the Scenario-Manager. For instance, moving a goal-object and connecting it 
to assumption-objects in the GUI. 

— request information/services from ActiveMath, e.g., the explanation of a 
method or of a definition, as well as from the proof planner, e.g., the current 
constraint collection, and pass the results to the GUI. This is important, since 
the learner should be able to actively request different kinds of supporting 
information. 
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— interpret proof plan changes, feedback and messages from the proof planner 
components and pass them to the GUI for display. This includes the change 
of the proof state as well as proof planning-related messages. For instance, 
if a method is not applicable because its application conditions are not true, 
then this feedback can be displayed appropriately because it might help 
a learner to correct her choice of a method or its details. Since the proof 
planner generates feedback in a technical format the learner is not supposed 
to understand, the GUI-Mediator has to interpret and filter this information 
to provide the learner with useful, comprehensible and possibly adaptive 
feedback. 

5 Adaptive Suggestions of the Glass-Box Service Multi 

The functionalities of black-box services, such as computer algebra systems, are 
mostly restricted to their original purpose and only few of them can be employed 
for means of adaptation. For instance, the computer algebra system Maple [12] 
can be called with assumptions for all following computations (e.g., a > 0) or 
certain functions can be excluded from the interaction. The restrictions may not 
be principled in nature and extensions similar to those described above may 
accommodate more adaptivity. 

Gompared with black-box systems the adaptive usage of glass-box systems 
such as Multi can be handled more easily. The simple reason is that we have 
more control over the functions of the glass-box and the extended architecture 
allows for adaptations. In what follows, we describe some directions of the adap- 
tivity for the interactive proof plan scenario in more detail. 

Adapting the Configuration 

The list of all parameters of a scenario is called a configuration. A configura- 
tion for interactive proof planning comprises 

— a proof planning strategy, 

— a set of suggestion agents, 

— the level of automation. 

The interactive proof planner comprises an agent-based mechanism for sug- 
gesting commands, which specify a method and the arguments necessary for its 
application to the current proof (see [4] for a detailed description). The set of 
suggestion agents controls the level of freedom in the interaction with the proof 
planner. It can be more or less restricted, more or less guided, and it can encode 
tutorial strategies such as the deliberate introduction of faulty suggestions for 
learning from failure. 

The Exercise Gomposer computes an initial set of agents from the specifica- 
tions of methods to be considered for the exercise problem. For instance, one 
set of agents suggests only applicable methods with all parameters instantiated. 
Another set of agents suggests only a partially specified method application, 
which has to be completed by the student. 
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If the author of an ActiveMath exercise wants to have a particular sugges- 
tion, e.g., a suggestion that corresponds to a typical error, then special agents 
can be added. The Exercise Composer evaluates these additional agents and 
combines them with the automatically generated ones. 

Two other parameters of the interactive proof planning scenario that are 
determined by the Exercise Composer are ‘strategy’ and ‘level of automation’. 
Proof planning strategies can implement different ideas for proving. That is, 
different strategies tackle a proof planning problem in a different way. If the 
Exercise Composer selects a strategy for the problem at hand, then it computes 
at least one agent for each method of the strategy. Some of the methods are 
pretty irrelevant for learning and therefore are applied automatically. The set of 
all those methods is called the level of automation. 

Selection of a Strategy 

A (proof) problem may be solvable by different (proof planning) strategies 
that represent different ideas of how to solve the problem. For instance, the 
general problem of classifying a residue class structure according to its algebraic 
properties (associativity, the existence of inverse elements, and isomorphy of 
residue classes) can be tackled by three different strategies (see [5]): the first 
strategy tries to solve the problem by applying known theorems, the second 
strategy reduces a residue class problem to a set of equations, which have to 
be solved, the third strategy introduces a case split over the (finitely many) 
elements of the residue class structure. 

The Exercise Composer chooses a strategy depending on the concrete prob- 
lem and on the knowledge of a learner (whether she knows the theorems that 
are the prerequisites of the first strategy, whether she knows the methods em- 
ployed by a strategy) and her performance in previous exercises (e.g., when the 
other strategies have been trained already) . Such configuration heuristics can be 
encoded by pedagogical rules. For instance 

IF studentKnowledge (prerequisites (f irstStrategy) ) > medium 
AND StudentKnowledge (f irstStrategy) < medium 
THEN present exercise-f or (f irstStrategy) 

IF StudentKnowledge (f irstStrategy) > medium 
AND StudentKnowledge (secondStrategy) > medium 
AND StudentKnowledge (thirdStrategy) < medium 
THEN present exercise-f or (thirdStrategy) 



Selection of Agents 

If the goal is to most rapidly prove a conjecture and deep learning is unim- 
portant, then the Exercise Composer generates agents for the configuration that 
check for applicability and provide only fully-specified, applicable suggestions. 
However, this is not a typical goal in learning to prove. Rather, learning involves 
to understand why a method is applicable, what a particular method is actually 
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doing, and for which purpose it is applied. Such competencies may be better 
trained when input is requested from the student (rather than clicking only) or 
while making mistakes, discover, and correct them. 

One method may correspond to several agents that differ in how specific their 
suggestions are, i.e., how much input is left to the student. For instance, an agent 
for a method, which has as arguments a goal and premises, can have suggesting 
agents for the premises or leave the selection of premises to the learner. 

Depending on the student model and the learning goal of an exercise, the Ex- 
ercise Composer chooses agents for a method that compute more or less complete 
suggestions. For instance, a novice learner would start with much support and 
fully-specified suggestions. For a more experienced learner, under-specification 
can force the learner to specify more input herself in order to discover and over- 
come misconceptions in the application of a method. 

An author-specified agent may request further arguments. For instance, one 
method for residue class proofs uses a computer algebra system to simplify a 
modulo-equation. An agent added by the author requests from the student to 
input the resulting term in advance. During interactive proof planning this input 
is compared with the actual result of the computer algebra system computation. 
The idea behind such an agent is to stimulate the anticipatory reasoning of the 
learner. 

Level of Automation 

The automation of the application of certain methods avoids bothering the 
learner with the specification of proof steps, which she already knows. Meth- 
ods that decompose logical quantifiers and connectives are typical examples for 
automated methods. Moreover, methods that perform some normalization or 
re-writing of assumptions and goals can be applied automatically, in case the 
learner is diagnosed to understand the outcome of these methods. 



6 Future Work 

6.1 Extensions of the Architecture 

The architecture in Fig. 1 (see section 4) enables a “one-shot” adaptive invo- 
cation of the Multi service. That is, when the Multi service is requested, the 
architecture enables the selection of a scenario and a configuration depending on 
the information in ActiveMath. During exercising, the configuration may turn 
out to be inappropriate for the student. For instance, gaps or faulty suggestions 
may be to difficult for the student. 

In order to allow for adaptation during an interactive exercise we are cur- 
rently developing and integrating a local student model as well as diagnosis and 
feedback components into the architecture in Fig. 1. 

Local Student Model. The local student model contains information about the 
user’s actions during the proof session and mastery information relevant in that 
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session. The local student model is maintained during the proof session only. 
It is initiated by the Exercise Composer with information from ActiveMath’s 
persistent student model. When a proof session terminates, the Evaluator inter- 
prets the information in the local student model and passes update information 
to ActiveMath’ persistent student model. The GUI-Mediator creates entries 
in the local learner history. 

Diagnose Component. With the help of Multi the diagnosis component analyzes 
the interactions of the learner as well as the proof progress during a session. It 
may use information in the local student model as well as information on the 
current proof state provided by the Scenario-Manager. The diagnosis component 
can change the local student model. 

Feedback Component. The feedback component uses the diagnosed and collected 
information in order to compute reactions. This comprises verbal feedback for 
the user (via the GUI-Mediator), new suggestions, or the modification of the 
configuration, i.e., the scenario setting, during an exercise. 



6.2 Deliver What the Learner Needs 

Crucial for the application of Multi for learning is a user-friendly GUI. This 
adaptive GUI has to hide technical details of the underlying proof engine. A first 
GUI will be specified based on the outcomes of Human Computer Interaction 
experiments with different groups of learners. Some features we identified already 
as crucial are a MathML-like quality of formula rendering, access of subformulas 
by mouse click, subformula drag&drop, and an input editor. 

Beyond the mere presentation in a GUI, for many functionalities in Multi 
(that can provide important information for an expert) we will have to exam- 
ine by experiments whether and to which extend they are usable by particular 
groups of learners. As an example, consider the collection of constraints during 
the planning process in a constraint store and the application of a constraint 
solver. The constraint solver provides valuable information for proof planning 
such as detection of inconsistencies to guide the proof planning and construction 
of instantiations of meta-variables. For the usage of this information for learning 
we have to examine questions such as: 

— for which learners is the provision of constraints suitable? 

— in which form should constraints be shown to particular groups of learners? 

— how should/can the consequences of actions to the constraint stores be 
demonstrated to learners? (e.g., the consequences of an instantiation of a 
meta-variable by the learner) 

— which learners can deal with information such as that their current goal is 
inconsistent with some collected constraints? 

~ how should such information be provided to particular groups of learners? 
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7 Conclusion and Related Work 

We described the architecture for the integration of a cognitive tool in a learning 
environment. For such a tool to be used for learning, additional components or 
features may have to be created rather than just a communication wrapper for 
Web-communication and brokerage. 

We have shown how adaptivity can be introduced for a proof planning service 
in order to adapt to the context and the needs of the learner. The adaptivity is 
realized by extensions of Multi as well as by the architecture that uses mediators 
that evaluate student model and context information to provide adaptive access 
to Multi and to a GUI. The architecture emphasizes the separation of different 
functionalities by different components. 

The concrete extensions of Multi are tool-specific. However, such extensions 
can be developed for other glass-box systems as well. 

For intelligent tutoring further components are necessary. In particular, we 
are currently designing a local student model and diagnosis and feedback compo- 
nents. Moreover, we started experiments to empirically test which functionalities 
of proof planning are suited for particular groups of learners and how to provide 
the functionalities to the learner in a usable way. 

Aspinall describes in [1] the Proof General Kit, which provides a general ar- 
chitecture for the integration of proof assistants with so-called display engines. 
The architecture consists of a collection of communicating components centered 
around the Proof General Mediator, which interfaces all the components and 
handles the communication between the components. This approach clearly sep- 
arates the GUI from the proof machinery and enables the integration of different 
proof assistents into a uniform framework with uniform presentations in different 
user interfaces. In our architecture, the mediators (the Exercise Gomposer and 
the GUI-Mediator) focus on the realization of adaptations. 
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Abstract. In this paper we present a mechanism for adding interactivity 
to static mathematical documents, which become interactive programs 
that allow students to practice the resolution of problems that involve 
symbolic computations. The designers that use this mechanism can work 
in the same environment used by students when solving the problems, 
and they don’t need to know any programming language. The original 
problems can also be generalized, and sets of similar problems that can 
be solved using the same methods can be generated automatically. The 
mechanism described has been implemented in a computer system that 
has also collaborative capabilities. 



1 Introduction 

Explanations about mathematics methods, or examples about applications of 
these methods, are usually included in static documents in a style similar to 
textbook pages. These documents lack an important feature that is desirable 
in a learning environment, namely interactivity, which allows learners to get 
involved in the learning process in a more participative way. In this paper we 
present a mechanism for adding interactivity to static documents, and at the 
same time structuring in a hierarchical manner the presentation of the informa- 
tion contained in them. 

In order to achieve the desired interactivity, it is essential to have an ade- 
quate level of structuring of the documents to be used. Mathematical documents 
usually consist of pieces of information with different levels of structure, such as 
formulae, graphics or text. This information is not usually structured according 
to rigid patterns, as opposed to computer-generated pieces of information, since 
for example it might correspond to pages within mathematics textbooks. In this 
context, semantic web efforts are well known to be addressed to the structuring 
of the information contained in documents, both in more general settings, [11], 
and in more particular ones, e.g. in mathematics [2], where they usually rely on 
mathematics representation languages, like MathML, [12]. 

Additionally, the parts that form mathematical documents, such as formulae 
or parts of them, are usually deeply interrelated. For instance, an explanation 
about a resolution method usually starts with some initial formulae and contin- 
ues with a series of steps using them to generate new ones, which in turn can be 
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utilized for new steps. A classical approach in order to deal with this issue, even 
though it should be mentioned that it is applied to purely numeric contexts, is 
the spreadsheet mechanism. On the other hand, formula evaluation is another 
major issue. For instance, it is usual to find the same value in a document several 
times with different degrees of evaluation, e.g. an arithmetical expression with 
parenthesis like (3+1)^ that is evaluated by first evaluating the expressions be- 
tween them, giving 3^ = 9. This also happens in the case of evaluations carried 
out by Computer Algebra Systems (CAS), [9], [10], where some mathematical 
expressions are completely evaluated. Sometimes these evaluations correspond 
to the resolution of a subproblem attached to a given resolution method. Besides, 
the degree of evaluation of the formulae is an issue that is not under a user’s 
control. 

Static documents basically serve as textbooks, with the added functionality 
of searching based on indexing, [2]. However, students prefer to get involved by 
making actions and receiving feedback from the documents. A basic example 
would be the case of spreadsheet documents where they not only can browse 
the information contained in them but they can also change values in certain 
cells, thereby receiving feedback showing them the result of the update of the 
constraints. 

A richer case of interactivity corresponds to the situation where students are 
able to enter expressions and answers to prompts from a computer system, or 
to choose options presented to them. For instance, at those decision points a 
student can be asked to choose a resolution method and accordingly the system 
will enforce it. This is the case of MathEdu, [4], which provides a rich interaction 
capacity built on Mathematica, [10], or Calculus Machina, [7], another advanced 
tutoring system with other features comparable to those of MathEdu. Still, there 
exists today a lack of authoring tools that allow teachers to establish this kind 
of interactivity in a simpler way, specially starting from static documents which 
can serve as sources for establishing the questions. Moreover, the interactive 
applications developed with these authoring tools should adapt to different sit- 
uations by including conditions for the applicability of the operations involved 
in a resolution method. 

In this paper we present a mechanism of the type described above for creating 
a model for the interaction with the student during the resolution of problems of 
Mathematics. This mechanism has been implemented in ConsMath, [5], a com- 
puter system that can be used while learning parts of Mathematics that involve 
symbolic computations. The major features of the system are the following ones: 

— ConsMath integrates both an authoring tool and an execution tool. By using 
the WYSIWYG authoring tool, teachers design interactive tutoring applica- 
tions in an intuitive and simple way, due to the similarity of the environments 
used by teachers and students. 

~ The design process carried out by teachers is done by using programming 
by demonstration methods, [3], which is an important technique belonging 
to the field of Human-Computer-Interaction. Thus, at each instant design- 
ers work with specific examples of resolution methods, and they identify 
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those examples as particular cases of more general methods generating sub- 
sequently a more general and abstract model. 

— By using ConsMath, an interactive application for the resolution of a cer- 
tain pattern problem can be built in a simple way starting from a static 
document that shows the resolution for a particular problem. This initial 
document can be generated by the designer either from scratch or by us- 
ing the ConsMath editor, which is able to import documents that include 
mathematical formulae written in the MathML language. 

— ConsMath has been built using a collaborative framework, [6]. As a con- 
sequence of this, students can learn collaboratively and teachers can inter- 
actively monitor their actions, based on the interaction model created by 
teachers. 

We have tested how ConsMath can be used for the design of interactive sets 
of problems. These tests have been performed by two math teachers. A collection 
of problems from the textbook [8] on ordinary differential equations has been 
designed. The teachers found that the resulting interactive problems are useful 
from the didactic point of view, the use of the tool is intuitive and simple, 
and they could not have developed anything similar without ConsMath. The 
teachers have also warned us that before using the system on a larger scale with 
less advanced users like students, the behaviour of the editor of math formulae 
should be refined. Since this editor is a third-party component, we are planning 
to replace it by our own equation editor in a future release. 

The rest of the paper is structured as follows: in the next section we shall 
describe from users’ perspective the use of ConsMath, i.e. teachers’ point of 
view in the process of creating a model for the interactivity of these applications 
by means of specifications by demonstration, and students’ point of view when 
using these models. We will do it by illustrating a relevant example. The following 
section will present a more detailed view of the system. Finally, conclusions will 
be presented about this work. 

2 Using ConsMath 

When working with ConsMath, students have to solve problems of Mathematics 
by answering the questions asked by the system. Fig. 1 shows the resolution 
of a problem for the computation of a limit, as it appears in the initial static 
document. Once the interactive problem is designed with ConsMath, the student 
can solve it. Then the statement is shown to him, and he has to answer the 
questions that are posed to him one after another. Fig. 2 shows the first question 
the system poses the student while solving the problem from Fig. 1. 

As an example of the dialog that can take place between a student and 
the system, if the student decides that the first step in the resolution of the 
problem in Fig. 1 is substituting sin a; by a; in the numerator, since they are 
equivalent infinitesimals, the system can show the student a simple case, like the 
computation of the limit oi (x - sin x) /x? ; this method obviously does not work. 
ConsMath can show the student the correct resolution of this simplified problem 
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together with the incorrect one, both of which are generated automatically on 
the bases of the work done by the designer. After this, the student is asked again 
about the resolution of the original problem. 

We shall describe now the way in which the designer can specify the dialog 
that takes place between the student and the system when in tutoring mode. 
When the designer starts his work with the initial static document, the resolution 
of the problem disappears and the statement of the problem stays in the screen. 
He can then add interactive components like the selection buttons in Fig. 2. The 
designer then specifies the actions to be taken when the student makes a selection 
by clicking on one of the possible choices; at this point the buttons disappear, the 
remaining part of the resolution of the problem appears again, and the designer 
can use it as part of the text to be shown to the student afterwards. He can also 
keep showing selection buttons or input fields until the problem is solved. 

In order to specify the dialog that takes place in case the student makes a 
different choice in the first step, the designer can use the left arrow that appears 
in the upper part of the design window, which allows him to turn back step by 
step to the same situation shown in Fig. 2. Then he can click on another button 
and start again the corresponding specification. The same can be done at each 
step of the resolution. 

The limit in Fig. 1 can be computed in several ways, like using L’Hopital’s 
rule or substituting the functions that appear by their Taylor expansion up to 
some degree. ConsMath, that can generate the problem randomly, is able to 
notice while the student is working which the possible methods of resolution 
are, and adapt accordingly its reaction to the answers given by the student. 
For example, in the case shown in Fig. 2, only the second, fourth, fifth and last 
possibilities are accepted. The fifth possibility gives rise to more questions that 
finally lead to a deadlock where the student has to recognize that the problem can 
not be solved, while the other possibilities can give rise to successful resolutions 
of the problem. Problem statements are generated randomly from statement 
patterns. These patterns include generalized formulae like the following one, 
which generalizes the formula in the problem in Fig. 1: 

A + Bx + C s\nx + Dx^ + Exsmx + F X 

lim — (1) 

x™ sm X 

where A, B, C, D, E, F, m and n can have arbitrary values within some bounds 
fixed by the designer. Many times the designer imposes other conditions on 
the initial generalized formulae. In the previous example, the designer can ask 
naturally for the existence of two coefficients in the numerator that are not 
null. In this case, when building a new specific statement, the coefficients are 
generated randomly one or more times until the desired condition is satisfied. 
ConsMath includes generators of random numbers within given intervals (integer 
or rational), and generators of random mathematical expressions of specific forms 
like polynomials or simple trigonometric functions. For example, in the previous 
pattern the numerator might also have been defined as a polynomial of degree 
2 in a; and sin x with the condition that it is not a monomial. 
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Fig. 1. Problem statement 

During the design of a problem, designers can alternate the way each for- 
mulae is shown between the specific formulae and the corresponding generalized 
one. This can be done by clicking on the formula with the right button of the 
mouse and making the choice they want. If the formula is not generalized, the 
generalized view will show the same information as the specific one. By editing 
the generalized formulae, designers can design them, as well as they can see the 
effect of their design on a specific example. 

When a formula depends on another one, like when substituting sin x by its 
Taylor expansion, 

x-^ + x^f{x) ( 2 ) 

ConsMath allows designers to propagate the generalization from the original 
formula to the other one by means of a spreadsheet mechanism based on the use 
of constraints among parts of formulae. For example, the numerator of the third 
formula in Fig. 1 can be generalized to 

3 3 3 

A + Bx + C{x— — + x^f{x)) + Dx^ + Ex{x— — + x^f{x)) + F{x— — + x^fix)Y 

6 6 6 

( 3 ) 

and its value is substituted automatically in it. The same effect can also be 
obtained by giving the function within the limit in formula 1 a name like Q, 
and substituting sin x by formula 2 instead of the quotient in the third formula 
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in Fig. 1. In this expression, the arrow indicates that a substitution has to be 
made. This can be done by just editing the generalized formula as indicated in 
the previous paragraph. 

As said before, each time a pattern is defined in order to generalize an initial 
formula, the designer can specify a condition that must be satisfied. This can be 
done by typing a condition in the corresponding input field that depends on the 
variables defined in the previous generalization process. Similarly, each time the 
designer specifies the behaviour of the system when the student makes a choice, 
he can specify a condition for its application. This can be done in the same way. 
Hence, for example, the designer can specify that the first choice in Fig. 1 can be 
accepted in case A=B=D=0 by just typing this condition on the corresponding 
input field. 



consmath 






File Edit View Window Help 

Insert Call Stop a Add Application Viewtemplate 

Text Field Equation Field Equation Button Radio Button First ^ Last New Dialog Hide Dialog Delete Dialog 

▼ Font Size 12 ▼ 
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Problem: Compute 



L= lim 



x^-sin^(x) 



X— 0 x^sin^x) 



Select the first resolution step: 

o 



o 



Substitute sin(X) by X in the numerator, since they are equivalent infinitesimal 
Substitute sin(X) byXin the denominator, since they are equivalent infinitesimal 



O 2 

^ Divide numerator and denominator by A 



O 



Apply L'Hopital rule 



® Divide numerator and denominator by W 
® Substitute sinpO by its Taylor developmentwith remainder of orders 
® Substitute sinpo by Its Taylor developmentwith remainder of order 4 



Fig. 2. Choice during problem resolution 



Analogously, designers can specify that the questions to be asked to the 
students when solving problems depend on the specific problem that is being 
solved. For example, in case A=B=D=0 in the above generalized problem, it 
makes sense to ask the student if he wants to factorize sin x in the numerator. 
This is also specified by means of conditions attached to the multiple choice 
buttons that show the different choices that are available in general. From this 
point of view, ConsMath is an adaptive system that admits different ways of 
resolution and reacts in different ways to the actions of the students depending 
on the specific problems that are being solved. Although a lot of work has been 
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done in the last years in adaptive tutoring systems, none of them depends on 
deep properties of mathematical formulae and they have many limitations from 
the point of view of the interactive specification of the problems without the 
need of any programming. 



3 ConsMath Architecture and Model 

ConsMath consists of several java applications that are distributed according 
to a client-server architecture (Fig. 3). It allows designers to create courses as 
described in the previous section and, besides, both the execution and the design 
of these courses can be done in a collaborative manner. 




Fig. 3. ConsMath Architecture 



In order to clarify the behaviour of ConsMath components, we will firstly 
describe each of them. These components are the following ones: 

~ An editor of mathematical texts, which supports symbolic relations among its 
components, and the specification of the interactivity using a programming 
by demonstration approach. This editor has two execution modes: the design 
mode (used by teachers), and the tutoring mode (used by students), which 
does not provide all the functionality of the design mode. 

~ The ConsMath server, which has a twofold functionality. Firstly, it serves 
as a central repository of courses or interaction templates, as courses are 
saved persistently creating a library, and secondly it provides mathematical 
expression evaluation capabilities. This second functionality is performed by 
using a CAS (currently Mathematica), so that that ConsMath Server acts 
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as a bridge between the CAS and the clients. As a consequence of these 
two functionalities, the ConsMath server simplifies the maintenance of the 
system and reduces costs, given that the clients just need the existence of one 
CAS running, which is at the server side, and the courses do not have to be 
replicated at each student’s machine. The ConsMath server communicates 
with each client using Java Remote Method Invocation (Java RMI). 

— The tracking agent is the component in charge of writing the interaction 
models during the design phase, and of interpreting these models in the 
tutoring phase. 

— The constraint manager is the component that keeps all the dependencies in 
the document updated, sending to the ConsMath interpreter the expressions 
to be evaluated. Consequently, parts of these expressions need to be evalu- 
ated by the CAS, in which case the interpreter sends them to the ConsMath 
server for their evaluation. 

— The collaboration agent is the ConsMath component which communicates 
with the collaboration services included in FACT, the collaboration frame- 
work used by ConsMath [6], in order to provide collaborative tutoring and 
designing support. The collaboration services are used by ConsMath users 
to participate collaboratively in the reviewing process as teachers or in the 
solving process as students. FACT is also written in Java and has a Client- 
Server architecture that communicates with the collaboration agent of each 
ConsMath client using Java RMI. FACT plays two main roles, firstly, it is a 
structured repository of collaborative sessions, which allows the users of the 
system, students or tutor, to collaborate in a problem resolution or review 
others work asynchronously, and secondly, it manages the synchronous col- 
laborative sessions, so the users of each synchronous session share the same 
information and the same state of the ConsMath clients. 

ConsMath users interact most of the times with the ConsMath editor. This 
editor can be used both by designers to create an interaction model and by 
students to execute this model. What designers do is to simulate user’s actions 
and the answer of the system to these actions, by using programming by example 
techniques as described in the previous section. The tracking agent interprets 
these actions at design time to create the interaction model. When the editor 
is in tutoring mode, the agent listens to the actions of the student to find the 
answer that must be given, according to the interaction model, and reproduces 
this answer. In the rest of this section we will describe the document model of 
the ConsMath Editor, and the interaction model. 



3.1 ConsMath Document Model 

In order to simplify the interaction, ConsMath documents can be divided in sub- 
documents, which can be hidden or locked to prevent the interaction of students 
with some parts of the document when in tutoring mode. 

Each subdocument is formed by HTML text combined with components that 
represent its non-textual part. The components that form ConsMath documents 
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can show formulae that correspond to MathML expressions or graphical func- 
tions. These components can be editors or browsers. There are also controls for 
the input of MathML expressions, multiple choice controls, buttons, and list 
boxes. 

The ConsMath’s constraint manager can relate the properties of the com- 
ponents. For example, ConsMath allows the construction of graphics that are 
updated automatically depending on some formulae that appear in the docu- 
ment. The constraint manager allows the specification of the properties of a 
component as ConsMath expressions, just like in a spreadsheet. Properties of 
components can be values or boolean conditions, like a property that specifies if 
a component is visible or not. On the other hand, the expressions that can define 
a property can include functions to give a name to some part of the expression, 
creating a variable, functions that evaluate an expression, or that incorporate 
the value of another variable in the expression, or functions that generate a 
mathematical expression randomly, with an associated pattern and a condition 
that the expression must satisfy. 

The constraint system is also responsible for the automatic conversion as 
needed between different types of expressions (boolean, MathML, Mathematica 
or OOCSMP, [1] properties). For example, the visible property of a component 
can be associated to a condition to indicate when that component must be shown. 
This condition can be written in MathML with embedded ConsMath functions. 
It can be specified using a WYSIWYG content MathML editor. 

3.2 Interaction Model 

The interaction model is represented by a tree where each path, from the root to 
each leaf of the tree, defines an abstract interaction sequence. Final interaction 
sequences can be more complex, because the abstract sequence can have cycles 
and calls to other interaction sequences, creating complex interaction models. 

This model is written by the tracking agent in the design phase creating a 
tree with two different interlaced zones, decision zones and performance zones. 
Decision zones are sub-trees with information to discriminate the different situa- 
tions that can be produced by the student actions. This information is acquired 
by the tracking agent when listening to the actions of the designer when sim- 
ulating the situations that can be produced later during the execution of the 
model by the students. For example, the designer can simulate that the student 
introduces the correct answer, later the designer goes back to the initial situ- 
ation by using the left arrow that appears into the upper part of the design 
window, as shown in figure 2, according to the explanation given in section 2, 
and introduces an invalid answer, creating a simple decision tree with only two 
alternatives. 

Each leaf of a decision tree is followed by a sequence of actions, in the per- 
formance zone, that correspond to the changes in the ConsMath Document that 
will take place after the situation described in the previous path of the decision 
tree is detected. The information of the actions in the performance zones is ac- 
quired by the tracking agent by listening to the actions of the designer when in 
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performance state. Also, performance zones can contain calls to other interaction 
models, or jumps to other points in the interaction tree. 

In order to create the interaction model the designer navigates through the 
model going backward and forward creating new alternatives in a decision tree 
or creating new performance sequences for a particular decision path, etc. The 
tracking agent follows the designer actions, creating new nodes of information in 
the tree that represents the interaction model. A typical decision tree is formed 
by a sequence of events for each alternative. At run-time, when the tracking agent 
is listening to the events produced by the interaction of students with the current 
document model, and the agent recognizes one of the sequences, it emits the 
corresponding answer that is codified in the performance zone of the interaction 
tree. The answer usually consists of a new sub-document of ConsMath, with a 
dialog, and another decision tree, or a call to another interaction model, which 
usually corresponds to a subproblem call. 

Also, the interaction model supports the combination, in any order, of dif- 
ferent types of decision trees, forming more complex decision trees. These types 
are: 



— Sequence decision tree: Is a tree where a path is matched when all events in 
the path take place in the order described by it. 

~ And decision tree: Is similar to the sequence decision, but the events can 
take place in any order. 

— Or decision tree: In this case only one of the events described in a path of 
the decision tree is necessary in order to match that path. 

The techniques described in this section allow the construction of a system 
as described in Section 2. 
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Abstract. We propose a mathematical knowledge browser which helps 
people to read mathematical documents. By the browser printed math- 
ematical documents can be scanned and recognized by OCR (Optical 
Character Recognition). Then the meta-information (e.g. title, author) 
and the logical structure (e.g. section, theorem) of the documents are 
automatically extracted. 

The purpose of this paper is to show the extraction method of logical 
structure specialized for mathematical documents. We implemented this 
method in INFTY which is an integrated OCR system for mathematical 
documents. In order to show the effectiveness of the method we made 
a correct database from an existing mathematical OCR database, and 
made an experiment. 



1 Introduction 

Computers became indispensable devices for mathematics. This phenomenon can 
be seen by the success of mathematical systems (e.g. Mathematica, Maple) which 
have been being used for various other fields such as physics and economics. 

In order to apply mathematics to the real world, mathematical knowledge 
should be stored in computers in a way that people can easily use. Even if more 
and more mathematics is done in formal ways, most of mathematical knowledge 
is still stored in papers or books. Therefore digitizing mathematical text is still 
important. 

1.1 Levels of Digitization 

There are several kinds of mathematics digitization. Adams gave some classi- 
fications of digitization of mathematics [1]. Based on this consideration, in this 
paper we introduce five levels of mathematics digitization. 
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— level 1: bitmap images of printed materials (e.g. GIF, TIFF), 

— level 2: searchable digitized document (e.g. PS, PDF), 

— level 3: logically structured document with links (e.g. HTML, MathML, 
DT)5X), 

— level 4: partially executable document (e.g. Mathematica, Maple), 

— level 5: formally presented document, (e.g. Mizar[6], OMDoc[4]) 

Currently most of mathematical knowledge is stored and used mainly in 
printed materials (level 1) such as books or journals. For being used actively it 
is preferable that mathematical text is stored in a possibly higher level of digiti- 
zation. However since making documents digitized to a higher level needs quite a 
lot of efforts, digitization of mathematical knowledge has not been enhanced so 
far. Therefore we definitely need software in order to automatize the digitization 
process in a possibly higher level. 



1.2 Technologies for Automatization 

The automatization can be achieved step by step: 

— level 1 to level 2: OCR (Optical Character Recognition), 

In order to retrieve searchable digitized document from bitmap images, OCR 
is used. With OCR, character sequences can be recognized from bitmap im- 
ages and then they can be used for searching words. Especially recognition of 
mathematical formulae is the most important in recognizing mathematical 
documents. The mathematical formulae recognition has been well investi- 
gated, e.g. [8]. 

— level 2 to level 3: Extracting Logical Structure and Hyper Links, 

Obtained data after OCR are basically characters having positions in a page 
structured by lines and areas. They do not directly contain meta-information 
(e.g. author, title) of a paper and structural information (e.g. section, subsec- 
tion) . Also they do not have hyper links which point to internal and external 
documents. 

— level 3 to level 4: Semantics Recognition from Presentation, 

Sometimes executable blocks (e.g. mathematical expressions, algorithms) ap- 
pear in mathematical text. In level 3 mathematical expressions are described 
in a two-dimensional (presentational) way. We need to extract semantic ex- 
pressions from these presentational expressions. Mathematica[10] has stan- 
dard collections of these transformation rules which retrieve semantics of 
presentational expressions and one can even define their own style of nota- 
tion (See MakeExpression function in [10]). 

— level 4 to level 5: Understanding Mathematical Document, 

Usually mathematical statements such as definitions, lemmata, theorems, 
and proofs are written in natural languages in books or papers. Therefore 
for treating them in computers we need natural language processing. The 
first step of the natural language processing is parsing. For parsing it is 
common to make a corpus which is a set of grammar rules extracted from 
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used expressions. Making a corpus for mathematical statements was achieved 
by Baba and Suzuki [2]. After parsing, formalizing written mathematical de- 
scription to logical formulae in a predicate logic can be achieved. Formalized 
statements can be used for proving in computers by theorem provers such 
as Theorema[3]. 

Since current our mathematical activities range over all digital levels, we 
need software which covers these all technologies from scanning to proving in 
a coherent manner. The ultimate goal is that scanned mathematical papers are 
processed and the software system gives us whether proofs are correct, though 
this goal is very ambitious. 

Since the ultimate goal is quite ambitious, as a sub-goal we propose a math- 
ematical knowledge browser which covers from level 1 to level 3 in Section 2. 
In order to make such a browser, some technologies are necessary. One of the 
technologies is to extract logical structure from documents after OCR. In Sec- 
tion 3 we discuss the method of extracting logical structure from mathematical 
documents. In order to show the effectiveness of the method, we made a correct 
database which can represent logical structure information based on an existing 
mathematical database for OCR, and experimented for the correct database. In 
Section 4 the correct database is described and the experimental result will be 
shown. Then we conclude the discussion in Section 5. 

2 Mathematical Knowledge Browser 

The mathematical knowledge browser helps people to do mathematics from level 
1 to level 3. One of inputs for this mathematical knowledge browser is a printed 
mathematical document. A printed document can be scanned, and then pro- 
cessed by OCR. After OCR logical structure and hyper links are automatically 
extracted and shown to users. 

We will implement this mathematical knowledge browser on an integrated 
OCR system for mathematical documents called INFTY[8] (INFTY can be 
downloaded^). INFTY reads scanned page images of a mathematical document 
and provides their character recognition results. One of the distinguished char- 
acteristics of INFTY is that it can recognize two-dimensional mathematical ex- 
pressions. INFTY has a graphical user interface which can show mathematical 
expressions in the ordinary two-dimensional mathematical notation, and has a 
manual error correction interface. The recognition results can be saved in various 
formats, e.g. XML (called KML), HTML, RTj;]X, Mathematica, and braille. 

2.1 User Interface 

The browser consists of three panes: structure pane, reference pane, browsing 
pane (Fig. 1). In the structure pane located in the left side, structural information 
is shown as a tree like a file manager. The browser pane on the right bottom and 
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Fig. 1. Screen Image of Mathematical Knowledge Browser (Sketch) 



the reference pane on the right top show mathematical text. By clicking a link 
in the browser pane, the text pointed by the link will be shown in the reference 
pane so that people won’t lose the attention in the browser pane. For example, 
by clicking the link ‘Lemma 2.1’ the reference pane shows ‘Lemma 2.1’ while the 
browser pane does not change. 



2.2 Showing Relationship of Mathematical Theory Structure 

Usually in a mathematical paper, mathematical components (e.g definitions, 
lemmata, theorems) have dependencies and one can construct a graph which 
shows the dependencies. With the mathematical knowledge browser one can see 
such dependency graphs. Fig. 2 shows an example of such a graph. For example, 
suppose ‘Lemma 3.1’ is used in the proof of ‘Theorem 4.2’, the text ‘Lemma 3.1’ 
should appear in the proof of ‘Theorem 4.2’. From this fact we can detect the 
dependency automatically. By this functionality, readers can recognize theory 
structure of a paper before reading into details. 



Theorem 4.2 



-Lemma 3.1 



Lemma 2.1 
-Lemma 2.2 



Lemma 3.2 



Fig. 2. Graph of Theory Dependency 
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Of course, showing theory structure is not a new idea. However the impor- 
tant point is that theory structure can be automatically extracted from printed 
mathematical documents. 



3 Extracting Meta-information and Logical Structure 

For realizing the mathematical knowledge browser, we need several technologies. 
One of the technologies is to extract meta-information and logical structure 
from mathematical documents. In this section, we discuss the method to extract 
automatically meta-information and logical structure. 

There are several studies of logical structure extraction from documents. 
Extensive surveys can be found in papers [5, 7]. In these studies target documents 
vary from general documents to specific documents. The work presented in this 
paper is unique because it is specialized for mathematical documents and it 
extracts mathematical specific components (e.g. Theorem, Proposition). The 
method proposed in this paper does not need to know layout styles beforehand, 
while some other studies do. 

3.1 Data Representation for Meta-information and Logical 
Structure 

INFTY[8] produces the following nested structure as output from scanned images 
as input. 

~ 1st page (size and position in the page) 

• 1st area (size and position in the page) 

* 1st line (size and position in the page) 

• 1st character (code, size and position in the page) 

• 2nd character (code, size and position in the page) 

* 2nd line 

* ... 

• 2nd area 

* 1st line 

• 1st character 



* ... 

— 2nd page 

A document contains several pages and each page contains several areas which 
have positions and sizes in the page. An area can contain lines which also have 
their positions and sizes. A line has recognized characters with positions, sizes 
and font styles. 

INFTY produces output in a XML format called KML. We extended the 
KML format so that it can represent meta-information and logical structure. 
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For example, Fig. 3 shows a result output in the extended KML for a scanned 
image shown in Fig. 4. The top element is ‘Doc’ which contains some ‘Sheet’ 
elements representing pages. A ‘Sheet’ element contains some ‘Area’ elements 
whose positions and sizes are indicated by ‘reef attributes. The value of the 
‘reef attribute " left, up, right, down" indicates the positions of left, up, right, 
down borders of the rectangle. An ‘Area’ element contains a ‘Text’ element 
having a ‘Field’ element. A ‘Field’ element has several ‘Line’ elements which 
have again several ‘Char’ elements. 

For the need of putting additional information for meta-information and 
logical structure we added the ‘tag’ attribute for the ‘Text’ element in order 
to represent the type of the text field. The values of the ‘tag’ attribute are 
‘PageHeader’, ‘PageNumber’, ‘Caption’, ‘Title’, ‘Authorinfo’, ‘AbstractHeader’, 
‘Abstract’, ‘Keywords’, ‘Headingl’, ‘Heading2’, ‘Headings’, ‘Headingd’, ‘Head- 
ings’, ‘Text’, ‘Referenceltem’, ‘Definition’, ‘Axiom’, ‘Theorem’, ‘MainTheorem’, 
‘Proposition’, ‘Corollary’, ‘Lemma’, and ‘Footnote’. 



3.2 Extraction Algorithm 

The algorithm of extracting meta-information and logical structure works in two 
steps: segmenting areas in a page and putting appropriate tags to the areas. In 
Fig. 4, areas are indicated by gray rectangles and their tags are put beside the 
rectangles. An area can be either a special text area (page number, running 
header, captions of tables and figures, footnotes, and headings) or a normal text 
area which can be a mathematical component (e.g. theorem, definition). Later 
the method to extract mathematical components is described in details. After the 
correct process of putting tags, the conversion to a logically structured format 
(e.g. HTML, OMDoc) is straightforward. 



Segmentation Segmentations can be done in the following three ways: 

— Segmentation by Spacing 

By using spacing information, scanned images are separated into several 
areas which can be either text areas, figure/table areas, or formulae areas. 

— Segmentation by Style Difference 

For each text area, the average size of the characters contained in the area 
is calculated. The size of a character can be determined by the height of 
the character. Also boldness can be calculated by the horizontal width of 
a character. In an area when the styles (bold, italic, and size) of lines are 
obviously different from those of other lines, they are separately segmented. 

— Segmentation by Keywords 

In an area, when a special keyword of mathematical components (e.g. Theo- 
rem, Lemma, Definition) comes in the beginning of a line, basically the area 
is segmented before the line. However sometimes there are cases that key- 
words do not indicate beginnings of mathematical components. This issue 
will be discussed in the next subsection. 
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<Doc version=" 1 . 1" language="English" ...> 

<Sheet id="l" doc_file_name="Arkiv_1997.kinl" 

image_f ile_name="Arkiv_1997_185 .tif " height="4438" width="3015" ...> 
<Area rect=" 148, 129, 1801, 266" id="l" ...> 

<Text rect="148, 129, 1801, 266" tag="PageHeader " ...> 

<Field base_char_size=" 16,30,13, 41" sub_char_size=" 11 , 20 , 9 , 28"> 
<Line id="l" rect=" 148 , 129, 1086, 195"> 

<Char code="0141" rect=" 148 , 133 , 195, 180" ...>A</Char> 

<Char code="0172" rect="200, 151 , 223, 180" ...>r</Char> 

</Line> 

<Line id="2" rect=" 149 , 200, 1801 , 266"> 

</Area> 

<Area rect="279, 948, 3022, 1239" id="2" ...> 

<Text rect="279, 948, 3022, 1239" tag="Title" ...> 

</Area> 

</Sheet> 

<Sheet id="2" doc_file_name="Arkiv_1997.kml" 

image_file_name="Arkiv_1997_186.tif" height="4432" width="3002" ...> 
<Area rect="229 , 169 ,326,215" id="l"> 

<Text rect="229, 169 ,326,215" tag="PageNumber" ...> 

<Field base_char_size=" 16,28,12,39" sub_char_size="ll , 19 , 8,26" > 
<Line id="l" rect="229, 169,326,215"> 

</Text> 

</Area> 

<Area rect="1088, 168,2358,228" id="2"> 

<Text rect="1088, 168,2358,228" tag="PageHeader" ...> 

<Field base_char_size=" 16,29,12, 40" sub_char_size=" 11 , 20 , 8 , 27"> 
<Line id="l" rect="1088, 168 , 2358 , 228"> 

</Area> 

<Area rect="231 ,405 ,3224, 701"> 

<Text tag="Theorem"> 

<Field> 

<Line id="l" rect="392, 405, 3224, 486"> 

<Char code="2154" rect="392,410,452,467" bold=" 1" . . . >T</Char> 
<Char code="2168" rect="458,409,506,467" bold=" 1" . . . >h</Char> 

</Area> 

<CharInf o> . . . </CharInfo> 

</Doc> 



Fig. 3. Example of KML Output from INFTY OCR Engine 
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Aik. H«i., » (1997), 185-lflB 
^ IM7 1™ iTMtitiit Mitt— -Lefflai. 




PageHeaderl 



Extension of smooth (JR mappings between 
non-essentially finite hypersurfaces in 



ifitlel 



Memi-Michel Mai re and Randne MeyknFl 

lAuthorlnfol 



n. Tntimriiirtinfl 



Heading! 1 



Let Af be a leal analytic hjrpermizfaoe in ooutaiiiiiig D and let Af ' be tht 
idsehraic Iq^arsur&ce in C’ defined 



[0.1) 






Fbr any t/<0, the fimction (*',u)')e->l/(tu'-iJ0 •» holeonorphle In 
Af'; tberefoie its restriction to Af' is a CR function which does not extend hcdO' 
raocpfaically arouml (0, 0, Uf). A clasracal argument using Baire's category theoren 
(see (HT, p. 125]) guarantees the existence of a CR function on M* which does no< 
extend to a full n«{diborhood of 0£C^. In contrast, fer CR mappings we have thi 
bHowing result. 



Text] 



Thearem 1. i» a smooth CR local diffeomorpfuBmWTTvB 

fe( 0)— 0. ft«m h extends io a AoJowuwTrfae fngpptfw in a full ne ighb orhood of Pin C?^. 

As we ehall see in Cctrallaiy 1.2, if h satisfies the hypothesis of the ttaeoren 
(more generally if his of fiaiiteinultiplicity) then Af is of finite type. After l^eprean’t 
theorem we know that ai^ CR function on M eKtends holomor{diicaRy to OTte ndc 
of M] thetrefve Theorem 1 is equivalent to a reflectkm principle (cf. Baouendi ant 
Rothschild [BR3|). Because we do not assume Af to be algebraic, and because hf U 
not essentially finite, Thecxem 1 does not follow horn the recent resutts of Baouendi 
R nang and Rotbschild [BHR] nor &om those of Baoueoadl and Rothschild [BR2| 
Notice that AT is hoknaorpMcally nan-degenerate in the saise of Stanton (Sj. 

Thoatem 1 may be generaliaed aa fiollows. 



Theorem] 



(^) The aecond author tob partiBlly auppofted by the SwlM N3F Grant 2000-042004.04/lj 



iText] 



Footnote] 



Fig. 4. Example of Scanned Image Separated by Areas 



Putting Tags to Areas. After the segmentation process, appropriate tags are 
put to these segmented areas. Here we describe criteria to decide appropriate 
tags for areas. 
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~ Title and Headings (e.g. section, subsection) 

In order to put tags to these area, areas are ordered by the following lexico- 
graphic ordering through a document. 

{Size, AllCapital, HCapital, Bold, Italic) 

Size: average size of characters contained in the area 

AllCapital:true if all characters are written in capital (e.g. SYSTEM) 
HCapital : true if only head characters are written in capital (e.g. System) 
Bold: true if characters are written in bold 

Italic: true if characters are written in italic 

The ‘Title’ tag is put to areas appeared in the upper part of the first page 
and is written in the largest area according to the lexicographic ordering 
above. Headings usually start from either some numbers separated by periods 
or special keywords like ‘Introduction’, ‘References’, ‘Bibliography’ in an 
emphasized (large/bold/italic) font. The tags ‘Headingl’,‘Heading2’, • • • are 
put to the second, third, • • • largest areas in the lexicographic order. 
Author Information 

The tag ‘Authorinfo’ is put to areas which come next to the title before 
headings or the abstract. 

Page Header, Footnote, and Page Number 

The ‘PageReader’ (‘Footnote’) tag is put to areas positioned in the top (bot- 
tom) of pages and written in smaller fonts than the average font size of text 
areas in a paper. The ‘PageNumber’ tag is put to areas which appear on 
the bottom or upper right or upper left of a page and consist of numbers in 
Arabic style or in Roman style (e.g. i, ii, iii, and iv). 

— Mathematical Components (e.g. definition, lemma, theorem) 

The tags for mathematical components are put to areas which start from the 
special keywords such as ‘Theorem’ and ‘Definition’. Here the problem is that 
these special keywords do not always indicate beginnings of mathematical 
components. The problem will be discussed in the next subsection. 

3.3 Two Difficulties in Extraction of Mathematical Components 

Correct extraction of mathematical components are important for further pro- 
cessing of mathematical documents, e.g. indexing, construction of dependency 
graphs, and understanding of mathematical statements. Here we describe two 
difficulties for extracting mathematical components. 

Looking for Beginnings of Mathematical Components. Basic idea of de- 
tecting beginnings of mathematical components is to look for special keywords 
(e.g. Theorem, Lemma, and Definition). However these special keywords do not 
always indicate beginnings of mathematical components. 

For example in Fig. 5, the 6th line starts with the keyword ‘Proposition’, 
but it is not the beginning of a proposition declaration. It appears in text in 
order to refer the ‘Proposition 3.4’ defined above. In Fig. 5 proposition com- 
ponents start from the keyword with all capital characters ‘Proposition’ which 
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Proposition 3.4. — Suppose that a > \. If f,g £ and 9*/ and 
dg are in L'f^ as well, then {dl,f,g)„ — {f,dg)a. That is, f e L'^ is in 
Dom9* if and only if 5*/ is in 

Since the the image of ^ i.s equal to /C„ for f; > 1, 

we have in partiiailar that f € , is in if and only if d*^f = 0. 

Proposition 3.4 is an immediate consequence of Proposition 3.3 and the 
following approximation lemma. 

Lemma 3.5. Suppose that V is a first order linear differential 

Fig. 5. Looking for Beginnings of Mathematical Components 



distinguish from other keywords like ‘Proposition’. However we can not assume 
that keywords of beginnings are written in all capital characters, because there 
are many other papers which have different styles. Therefore we need a general 
algorithm in order to detect styles of mathematical components. In Section 3.4 
the method will be described in details. 

Looking for Endings of Mathematical Components. Looking for endings 
of mathematical components is not so easy task. For example, in Fig. 6, the fifth 
line is the ending of the lemma. In this case, the lemma is written in italic till the 
fifth line and from the sixth line it turns into normal font. Therefore the ending 
of the lemma can be detected. It is usual that lemmata or theorems are written in 
italic. Of course we can not assume that these components are written in italic. 
Additionally definitions usually are not written in italic. Another criterion can 
be indentation or space between lines. In this paper, we simply look for the 
style change from italic to normal font for mathematical components except 
definitions, and for definitions we look for indentation. 



Lemma 4.1. i) If xs H*(G/H ■, k) is transgressive with respect to the bot- 
tom fibering, then the element p*(x) e H*(G ; k) is universally transgressive. 

ii) If xeH*(G; k) is universally transgressive then so is j*(x)e H*(H ; k). 

iii) If H‘{G/ H \ k) = 0 for i<n, degAr<n— 1 for xeH*{G\k) and if j*(,x) 
is universally transgressive, then x is also universally transgressive. 

These follow from the naturality of the transgression. 

The following result is due to Borel [4] (see also Baum-Browder [2]). 

Lemma 4.2. We can choose generators a, x„ x„, jr,„+,s//*(PSp(2n+l) ; Zf) 

such that H*(PSp(2n^l) ; Zf) = Zfia2/{a*)<SlA(.x„ ••• , at,„+j) where dega=l 
and 7r*(.r„.,)=e4,.i, i=2, 3, •••, 2n+l, for the projection n : Sp(2n+l)-*PSp(2n+l). 

Fig. 6. Looking for Endings of Mathematical Components 



When a mathematical component spreads over more than one page, failure 
detection of ‘PageHeader’, ‘Footnote’, ‘PageNumber’ causes failure of looking 
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Table 1. Lin2e Features 



Line Feature 


Explanation 


BK-Definition 

BK-Theorem 

BK-Proposition 

BK-Corollary 

BK-Lemma 

K-Italic 

K-Bold 

K-LCapital 

K-SCapital 

Indented 


The line begins from the keyword ‘Definition’. 

The line begins from the keyword ‘Theorem’. 

The line begins from the keyword ‘Proposition’. 

The line begins from the keyword ‘Corollary’. 

The line begins from the keyword ‘Lemma’. 

The keyword is written in italic. 

The keyword is written in bold. 

All characters of the keyword are in large capital, (e.g PROPOSITION) 
Most of characters of the keyword are in small capital, (e.g. Proposition) 
The line is indented. 



for endings of mathematical components. Therefore detection of ‘PageHeader’, 
‘Footnote’, ‘PageNumber’ is very important. 

3.4 Algorithm for Detecting Styles of Mathematical Components 

In a paper, for a mathematical component the formatting style is uniform in 
principle. The idea of the algorithm for detecting styles of mathematical com- 
ponents is to use the style uniformity of a mathematical component. 

The algorithm for detecting styles of mathematical components is described 
in Fig. 7. At first features shown in Table 1 are extracted from lines, and then 
for each line two style values ‘lineDefStyle’ and ‘lineCompStyle’ are calculated. 
The variable ‘lineDefStyle [i]’ stores the style value of the zth-line and is for 
detecting the beginning of a definition mathematical component. The variable 
‘ lineCompStyle [i]’ is for detecting other mathematical components, since most 
of the cases styles of mathematical components except definitions are the same. 
If the line does not start from a special keyword of mathematical components, 
the style value becomes ‘-1’ which means that it can not be the beginning of a 
mathematical component. Then the most frequent style values in a paper decide 
the styles of beginning lines of mathematical components and the style values 
are assigned to the variables ‘defStyle’ and ‘compStyle’. Finally when the style 
value of a line is not ‘—1’ and it coincides with the most frequent value, the line 
is the beginning of a mathematical component and the process of looking for the 
ending is executed. 

4 Experiment 

In order to see the effectiveness of the algorithm we made an experiment for a 
correct database. 

4.1 Outline of Database 

We added new information for logical structure to a large-scale database of 
mathematical documents[9, 8] and made the correct database which can be used 
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// calculating the style value for each line 
for i=l to number_of_lines (paper) f 
If =extract_features (paper . line [i] ) // extracting line features 
// The number means that the line can not be 

// the beginning of a mathematical component. 
lineDef Style [i] = if (If .BK-Def inition, stylefunc(lf ) , -1); 
lineCompStyle [i] =if (If .BK-Theorem || If .BK-Proposition || 

If . BK-Corollary || If .BK-Lemma, stylefunc(lf ) , -1); 

} 

// detecting most frequent style values 
def Style =most_frequent (lineDef Style) ; 
compStyle=most_f requent (lineCompStyle) ; 

// looking for endings 
for i=l to number_of_lines (paper) { 
if ( ! (def Style==-1) && lineDef Style [i] ==def Style) { 
segmentAreaO ; 

look_f or_ending_by_Indent (i) ;)■ 
if ( ! (compStyle==“l)&& lineCompStyle [i] ==compStyle) { 
segmentAreaO ; 

look_f or_ending_by_Italic (i) ;)■ 



}; 

int styleFunc(LineFeatures If) 

{ return (If . K-Italic*2‘0+lf . K-Bold*2~ 1+lf . K-LCapital*2‘2+lf . K-SCapital*2‘3 
+lf . Indented*2''4) ; } 



> 



Fig. 7. Algorithm for Detecting Styles of Mathematical Components 



for the experiment. The documents contained in the database are 29 English 
articles on pure mathematics (issued in 1970 - 2000). Basically for each journal 
two old and new papers are selected. The numbers of pages and characters in the 
database are 422 and 706,279, respectively. This database is larger than other 
databases used in the past researches on math-OCR. 

All pages were scanned in 600 dpi and binarised automatically by the same 
commercial scanner (RICOH imagio Neo 450). The quality of resulting page 
images are noisy and include a lot of abnormal characters, such as touching 
characters and broken characters. The maximum and minimum abnormal char- 
acter rates, which represent the quality of images, are 12.6% and 0.11%, respec- 
tively. 

4.2 Experimental Result 

We implemented the algorithm within the INFTY system and compared with 
the correct database described above. The result is summarized in Table 2. When 
there are miss-recognitions of characters, the keywords used for detection are not 
effective for looking for beginnings of mathematical components. Therefore it is 
considered that ‘Success’-|-‘Miss-Recog.’ approximates the real success numbers 
for the method described in this paper. 
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Table 2. Experimental Result 



TagName 


Correct 


Success 


Begin- 


End- 


TagErr 


Miss- 


Ratel 


Rate2 








AreaErr 


AreaErr 




Recog. 


(%) 


(%) 


PageHeader 


425 


418 


1 


3 


3 


0 


98.4 


98.4 


PageNumber 


398 


381 


11 


0 


6 


0 


95.7 


95.7 


Title 


28 


27 


0 


1 


0 


0 


96.4 


96.4 


Authorlnfo 


28 


23 


1 


3 


1 


0 


82.1 


82.1 


Headerl 


126 


113 


2 


1 


10 


0 


89.7 


89.7 


Header2 


14 


13 


0 


1 


0 


0 


92.9 


92.9 


Footnote 


16 


10 


5 


0 


1 


0 


62.5 


62.5 


Definition 


31 


24 


3 


4 


0 


0 


77.4 


77.4 


Theorem 


116 


103 


6 


6 


1 


2 


88.8 


90.5 


Main theorem 


2 


2 


0 


0 


0 


0 


100.0 


100.0 


Proposition 


91 


83 


5 


3 


0 


0 


91.2 


91.2 


Corollary 


36 


31 


3 


0 


2 


2 


86.1 


91.7 


Lemma 


107 


92 


8 


6 


1 


2 


86.0 


87.9 


Total 


1418 


1320 


45 


28 


25 


6 


93.1 


93.5 



‘Correct’ number of areas in the correct database. 



‘Success’ number of success tagging by the method proposed in this paper. 

‘Begin- AreaErr’ number of errors to detect beginnings of areas. 

‘End-AreaErr’ number of cases which detected beginnings of areas, 
but failed to detect endings of areas. 

‘TagErr’ number of errors that different tags were put. 

‘Miss-Recog.’ number of miss-recognitions by OCR for the special keywords. 
‘Ratel’ success rate computed by Success/ Correct * 100. 

‘Rate2’ success rate computed by (Success -I- Miss-Recog.) /Correct * 100. 



Main reason of the failures in detecting mathematical components is that the 
method fails to detect endings of mathematical components because of the simple 
ending detection method. Improving the method will improve the recognition 
rate. 

5 Conclusion 

A method of extracting meta-information and logical structure from mathemati- 
cal documents was presented and implemented on the base of the INFTY system. 
In order to show the effectiveness of the method, we made an experiment and the 
recognition rate was 93.1% in the practical situation including miss-recognitions 
of characters by OCR. We are now increasing the number of papers contained 
in the correct database in order to experiment for larger amount of papers. 

The improvement of the recognition accuracy can be achieved by giving ad- 
ditional information to the system. For example, knowing journal names, which 
may be automatically extracted from running headers, can contribute to the ac- 
curacy, because a journal has its own format. Also when the system fails to detect 
logical structure, a little human interaction can contribute to the accuracy. 
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With the facility of automatic linking, we will be able to implement the math- 
ematical knowledge browser based on the INFTY system. The mathematical 
knowledge browser can be extended to a system for editing mathematical doc- 
uments. With the editor one can input mathematical statements in formalized 
formulae. The formalized formulae can be sent to computing, solving, proving 
services located in the Internet and the results can be obtained. Namely it can 
be used as a front-end for mathematical services. We expect this mathematical 
knowledge browser to become a digitalization tool for mathematics, and enhance 
mathematical activities. 
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Abstract. In this paper we report on the current state of implementa- 
tion of two features of the Mizar system - properties and requirements. 
These two mechanisms provide elements of basic computer algebra to 
strengthen the capabilities of the Mizar checker by automation of some 
frequently used reasoning steps. This, in turn, allows for a notable re- 
duction of the size of users’ input in some reasonings. As a result, the 
size of the Mizar library can be reduced, and, at the same time, Mizar 
articles can become more like informal mathematical papers. 



1 Introduction 

The original goal of the Mizar project was to design and implement a software 
environment to support writing traditional mathematics papers. Mathematical 
practice shows that even in formal proofs some easy background reasoning can, 
and in many cases should, be reduced for the sake of clarity and the comfort of 
both writers and readers. Although Mizar inference checker uses model elimi- 
nation with stress on processing speed (not power), its power can be extended in 
several ways (cf. [15]). Typically, such extensions are coded in equalizer ~ the 
module responsible for the equality calculus in the Mizar checker (cf. [20]). In 
this paper we describe the current state of implementation of two features which 
serve that goal. Namely, we discuss how certain properties can be associated 
with Mizar definitions and how the requirements directive can strengthen the 
process of inference justification in Mizar. Their effects can substantially reduce 
the amount of justification an author must provide in a proof. Used in connec- 
tion with suitable management utilities these features stimulate the growth and 
evolution of the MML^. 



^ The Mizar Mathematical Library (MML) is the official database of Mizar articles. 
Its systematic collection started in 1989. At the time of this writing it contains 842 
articles (about 60 MB of Mizar texts). 



A. Asperti et al. (Eds.): MKM 2004, LNCS 3119, pp. 290-301, 2004. 
© Springer- Verlag Berlin Heidelberg 2004 
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2 Properties 

As described in [17], there are four main kinds of constructors in Mizar: predi- 
cates, functors, modes, and attributes. Mizar allows for special automated pro- 
cessing of certain properties of the first two types. When a symbol of a given 
property is included in a definition of a predicate or a functor, a suitable for- 
mula can be automatically used by the Mizar checker in every inference step 
which concerns that constructor. In that case, corresponding statements and 
references to these statements become superfluous. Of course, the properties are 
paired with a justification of suitable correctness conditions which we describe 
in the sequel. We also discuss the restrictions which seem necessary to avoid a 
collapse of type system consistency. 

The properties currently implemented for predicates (constructors of formu- 
lae) include: asymmetry, connectedness, irref lexivity, reflexivity, and 
symmetry, so they are applicable to binary predicates. The properties for functors 
(constructors of terms) are: commutativity, idempotence, involutiveness, 
and pro j activity. The tables below present the number of occurrences of all 
properties in the current MML (ver. 4.09.842). 



Predicate property 


Occurrences 


reflexivity 


91 


symmetry 


85 


connectedness 


9 


irref lexivity 


8 


asymmetry 


4 



Functor property 


Occurrences 


commutativity 


121 


idempotence 


85 


proj activity 


9 


involutiveness 


8 



Some of the occurrences are a result of specifically intended MML revisions. 
Others were introduced originally by authors of new contributions encouraged 
to use properties where applicable. It should be also possible to identify already 
existing MML definitions suitable for introducing properties with MMLQuery. 

2.1 Predicate Properties 

In general, a Mizar predicate with properties is of the form: 

definition 
let X be 0 i; 
let y be 62 ', 

pred Example_Pred x,y means 
6(x,y); :: the definiens of the predicate 

predicate-property-symbol proof ... end; 



end 
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where predicate-property- symbol stands for one of the following: asymmetry, 
connectedness, irref lexivity, reflexivity, and symmetry (in the current 
implementation the properties are allowed only when the types 9i and 02 are 
equal) . 

The set of implemented predicate properties is not purely accidental as it 
may appear at first glance. One may easily check that they form the set of all 
meaningful universal formulae which can be obtained by combining occurrences 
of P[x, y\ and P[y^ x\ with logical connectives (reflexivity and irref lexivity 
being a special case with x = y). Moreover, since every Mizar predicate can 
have an euitonym, each property must have a counterpart related to the antonym. 
One may observe that reflexivity automatically means irref lexivity for an 
antonym and vice versa. The same can be said for the pair connectedness and 
antisymmetry. Obviously, symmetry of an original constructor and its antonym 
are equivalent. 

The following table contains a summary of predicate properties with suitable 
justification formulae. Examples of all properties taken from MML are presented 
below. 



Predicate property 


Formula to be proved as justification 


asymmetry 


for x,y being 9\ holds ^(x,y) 
implies not ^(y,x) 


connectedness 


for x,y being 9\ holds not 6(x,y) implies 0(y,x) 


irref lexivity 


for X being 9\ holds not 6(x,x) 


reflexivity 


for X being 9i holds 6(x,x) 


symmetry 


for x,y being 9i holds ^(x,y) implies 6(j,x) 



We can illustrate asymmetry with the Mizar primitive ’in’ predicate. This 
predicate property has no accompanying justification because it is built into the 
Mizar system (the article HIDDEN ([12]) which documents built-in notions). 

definition 
let x,X be set; 
pred X in X; 
asymmetry; 
end; 

To demonstrate connectedness we can look at the redefinition of inclusion 
for ordinal numbers (ORDINALI, [3]). 

definition 
let A,B be Ordinal; 
redefine pred A c= B; 
connectedness 
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proof 

let A,B be Ordinal; 

A in B or A = B or B in A by Th24; 
hence thesis by Def2; 
end; 
end; 

Here, Th24 and Def2 refer to: 
theorem Th24: 

for A,B being Ordinal holds A in B or A = B or B in A 

definition let X be set; 
attr X is epsilon-transitive mesms :Def2: 
for X being set st x in X holds x c= X; 
end; 

An example of a predicate with irref lexivity is the proper inclusion of 
sets (XB00LE_0 : def 8^, [7]). It sometimes happens, as in this example, that the 
condition is simply obvious for the checker, because in the definition block the 
definiens is automatically available. 

definition let X,Y be set; 
pred X c< Y means :Def8: 

X c= Y & X <> Y; 
irref lexivity ; 
end; 

As an example of the symmetry property we can show a predicate satisfied 
whenever two sets have empty intersection (XB00LE_0 : def 7, [7]). 

definition 
let X,Y be set; 
pred X misses Y means :Def7: 

X /\ Y = {}; 
symmetry; 
end; 

An example of ref lexivity is the divisibility relation for natural numbers 
(NAT_l:def 3, [1]) presented below: 

definition 

let k,l be natural number; 
pred k divides 1 means :Def3: 
ex t being natural number st 1 = k * t ; 
ref lexivity 



^ The phrase Article- Identifier.dei Definition-Number follows the convention which 
identifies all Mizar definitions in the MML. 
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proof 

let i be natural number; 
i = i * 1; 
hence thesis; 
end; 
end; 

We should note that a concept similar to predicate properties could also be 
implemented for modes since they are in fact special kinds of predicates. For 
example, reflexivity seems useful for a mode constructor like ’Subset of’. 

2.2 Functor Properties 

The binary functor properties in Mizar are commutativity and idempotence. 
In general, we write a binary functor with properties in the following form: 

definition 

let X be 9i, let y be 62 ] 
func Example_Func(x,y) -> 9^ means 
5(it,x,y) ; 

binary-functor-property-symbol proof ... end; 
end; 

where binary-functor-property-symbol is commutativity or idempotence, and 
Mizar reserved word ’it’ in the definiens denotes the value of the functor being 
defined. 



Binary functor property 


Formula to be proved as justification 


commutativity 


for X being 9s, y being 9i, z being 02 
holds 0(x,y,z) implies 0(x,z,y). 


idempotence 


for X being 9i holds 6(x,x,x) 



An example with both binary functor properties is the set theoretical join 
operator (XB00LE_0 : def 2, [7]). 

definition 
let X,Y be set; 

func X \/ Y -> set means :Def2: 

X in it iff X in X or X in Y ; 
existence proof . . . end; 
uniqueness proof . . . end; 
commutativity; 
idempotence ; 
end; 
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With current implementation, the commutativity is only applicable to func- 
tors for which the result type is invariant under swapping arguments. Further- 
more, idempotence requires that the result type be wider than the type of the 
argument (or equal to it). 

Mizar unary functors with properties use the form below: 

definition 
let X be 9i, 

func Example_Func (x) -> 02 means 
5(it,x) ; 

unary-functor-property-symbol proof ... end; 
end; 

where unary-functor-property-symbol is involutiveness or projectivity. The 
system consistency is protected by the restriction that types 6 i and 62 be equal. 



Unary functor property 


Formula to be proved as justification 


involutiveness 


for x,y being 01 holds ^(x,y) implies 6 Cy,x) 


projectivity 


for x,y being 01 holds ^(x,y) implies SCx,x) 



The involutiveness is used for example in the definition of the inverse 
relation (RELAT_l:def 7, [21]). 

definition 
let R be Relation; 
func R~ -> Relation means :Def7: 

[x,y] in it iff [y,x] in R; 
existence proof . . . end; 
uniqueness proof . . . end; 
involutiveness ; 
end; 

As an example of the projectivity property we give the functor for gener- 
ating the absolute value of a real number (ABSVALUE : def 1, [16]). 

definition 

let X be real number ; 

func abs x -> real number equals :Defl: 

X if 0 <= X 
otherwise -x; 

coherence ; 
consistency; 

projectivity by REAL_1:66; 
end; 
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Here, REAL_1:66 ([14]) refers to: 
theorem :: REAL_1:66 

for X being real number holds x < 0 iff 0 < -x; 

Due to some problems in implementation the idempotence, involutiveness, 
and projectivity properties are still not available for redefined objects. 



3 Requirements 

The requirements directive, which is comparatively new in Mizar, allows for 
special processing of selected constructors. Unlike the properties described in 
Section 2, it concerns the environ part of a Mizar article (cf. [17]). With the 
requirements directive, some built-in concepts for selected constructors will be 
imported during the accommodation stage of processing an article (importing 
information from the database to create a local environment). In the MML 
database they are encoded in special files with extension ’.dre’. As yet, the 
special files in use are: HIDDEN, BOOLE, SUBSET, NUMERALS, REAL, and ARITHM^. 
Below we describe how they assist the Mizar checker with the work of reasoning 
so that the amount of justification an author must provide can be reduced^. 

However, the approach adopted in the Mizar system is to use possibly min- 
imal set of internally built-in requirements. It is preferable to use as much as 
possible “natural” Mizar techniques. For instance, this is often the case with 
attributes where a quite powerful mechanism of cluster registrations is used to 
provide significant automation of reasoning (cf. 3.5). 

3.1 Requirements HIDDEN 

This directive is automatically included during accommodation of every article 
and therefore does not need to be used explicitly. It identifies the objects defined 
in the axiomatic file HIDDEN, i.e., the mode set followed by the ’=’ and ’in’ 
predicates (hidden : def 1 - HIDDEN:def 3, [12]). Mode set is the most general 
Mizar mode and every other mode widens to it. Thanks to the identification 
provided by requirements HIDDEN it is used internally wherever the most basic 
Mizar type is needed, e.g. while generating various correctness conditions. The 
fundamental equality predicate ’=’ is extensional which means that two objects of 
the same kind (atomic formulae, types, functors, attributes) are equal when their 
arguments are equal. This particular property is used frequently by the Mizar 
checker. The ’=’ relation is also symmetric, reflexive and transitive. Predicate 



® Historically, the first requirements directive was ARYTM, introduced in 1995. It is 
also the one which has been changed most recently (the name was also changed into 
ARITHM in 2003). 

^ Recently, the Mizar Library Committee decided to provide special articles cover- 
ing the proofs of requirements which can be formulated as Mizar statements (cf. 
[8], [6], [13], [10], and [5]. 
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’in’ plays an important role in the ’unfolding’ of sentences with the Fraenkel 
operator in positive and negative contexts. This allows sentences of the form 
ex y being 9 st x=y & P [y] to be true whenever x in {y being 6 : P[y]} 
is true and vice versa. Various features of the ’in’ predicate are considered in 
conjunction with other requirements (cf. Sections 3.2, 3.3). 

3.2 Requirements BOOLE 

When processing an article with requirements BOOLE, Mizar treats specially 
the constructors provided for the empty set ({}), attribute empty, set theoret- 
ical join (\/), meet (/\), difference (\) and symmetric difference (\+\) given 
in definitions XB00LE_0:def 1-XB00LE_0 : def 6, [7]. It allows the following 
frequently used equations to be accepted without any external justification: 
X \/ {> = X, X /\ {} = {}, X \ {} = X, {} \ X = {}, and {} \+\ X = X. 
The empty set also gets additional properties: x is empty implies x = {}, 
and similarly x in X implies X is non empty. Finally, the attribute empty is 
added to all occurrences of the numeral 0 and, similarly, non empty to all other 
numerals. Additional features concerning emptiness are also described in 3.3, 
3.4, and 3.5. 

3.3 Requirements SUBSET 

This requirements directive concerns the definition of inclusion (TARSKI : def 3, 
[18]), the power set (ZFM1SC_1 :def 1, [4]) and also mode ’Element of’ (SUBSET_1 
:def 2 with a redefinition that follows it, [19]). Inclusion and the power set 
are denoted as c= and bool, respectively. With this directive, X c= Y auto- 
matically yields X is Element of bool Y and vice versa (a shortcut mode no- 
tation X is Subset of Y can be used instead of X is Element of bool Y). 
The property of the form x in X & X c= Y implies x in Y is incorporated 
as well®. Also, when processing x in X the condition x is Element of X is 
generated. When BOOLE is also applied in the requirements directive, the for- 
mula X in X is equivalent to x is Element of X & X is non empty (cf. 3.2). 
Additionally, x in X & X is Element of bool Y yields Y is non empty. 

3.4 Requirements NUMERALS 

This directive enables special processing of the successor operator (ORDINALI : def 
1, cf. [3]). The value of succ is calculated for variables with numeric value, so for 
example statements like x=2 implies succ(succ(succ(x) ) ) = succ (succ (3) ) 
are accepted automatically. Another function of this directive is to generate the 
type Element of omega for any numeral, so in fact to provides the correspon- 
dence between numerals and numbers defined in the MML. With an empty 
requirements directive numerals are just names for (not fixed) sets. This re- 
quires also SUBSET to be present in the requirements directive in order to 
understand the mode ’Element of’. 



® Formerly, it was an extensively used MML theorem BOOLE: 11. 
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The attribute natural (0RDINAL2 : def 21, cf. [2]) is also identified with this 
directive, but currently there is no special processing for it in the Mizar checker. 



3.5 Requirements REAL 

Comparing to the previous implementation described in [15], the role of this 
directive has completely changed as a result of the changes in the internal repre- 
sentation of numeric values. The features formerly associated with REAL are now 
a part of ARITHM (cf. 3.6). Currently, this directive identifies the ordering relation 
on real numbers (<=) and the attributes positive and negative (XREAL_0:def 
2-4, cf. [11]) Each occurrence of x <= y is processed according to the following 
attribute calculus: 

— if X is positive then y is positive 

— if y is negative then x is negative 

— if X is non negative then y is non negative 

— if y is non positive then x is non positive 

Any negated occurrence of x <= y yields the following: 

— if X is non positive then y is negative 

— if y is non negative then x is positive 

When the directive BOOLE is also used (the attribute zero is a synonym for 
empty which can be used for numbers), the checker accepts additionally the fol- 
lowing clauses: 



X <= y & y is non zero & x is non negative implies y is positive 
X <= y & X is non zero & y is non positive implies x is negative 

It would be possible to include also other (more specific) conditions on the 
attributes. But according to the adopted approach to use (when possible) “nat- 
ural” Mizar mechanisms rather than built-in knowledge, other consequences 
should be available to the checker as a result of processing conditional cluster 
registrations (XREAL_0, cf. [11]) as below: 



registration 

cluster positive -> non negative non zero 
cluster non negative non zero -> positive 
cluster negative -> non positive non zero 
cluster non positive non zero -> negative 
cluster zero -> non negative non positive 
cluster non negative non positive -> zero 
end; 



(real number) ; 
(real number) ; 
(real number) ; 
(real number) ; 
(real number) ; 
(real number) ; 



This directive is also required by the Mizar checker to automatically set the 
order between numerals. 
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3.6 Requirements ARITHM 

Current specification of requirements ARITHM concerns the basic operations on 
complex numbers: addition (+), multiplication (*), the negative element (-), the 
inverse element ("), subtraction (-), and division (/) defined in XCMPLX_0:def 
4-9, the attribute complex (XCMPLX_0 : def 2), and also the imaginary unit <i> 
(XCMPLX_0 : def 1, cf. [9]). The above functor constructors are used in equalizer 
- the module responsible for the equality calculus in the Mizar checker (cf. [20]) 
to associate every equivalence class (in a given inference step) with a unique 
symbolic polynomial in the canonical form: 

ag + + • • • + 

Each Jfij represents a term which is irreducible with respect to the above 
functor constructors and whose type widens to complex number, aj are numeric 
(complex) constants. Numeric values are represented as rational complex num- 
bers (complex numbers with rational numbers as imaginary and real parts). 
The numerators and denominators of Mizar numerals must not be greater than 
32767 (the maximum value for a 16-bit signed integer), although all internal cal- 
culations are based on 32-bit integers. This implementation, however, is about 
to change in near future in order to enable calculations on integers of arbitrary 
length. 

This apparatus allows for significant reduction of user’s input in reasonings 
involving numbers. Quite complicated equalities are now accepted by the checker 
with no additional justification, like in the following example: 

z*2*(x+y)/2-z*z = ((z*(x-(z+-l*y)))+(z*(x-(z-y))))*2" 

where both sides are equal because they are reduced internally to the polynomial 
xz + yz — At the same time, thanks to the calculus of polynomial forms, the 
associativity of arithmetic operations is also solved automatically, which was 
often reported by users as one of the most irksome hindrances in using the 
Mizar system. 



4 Conclusions 

The idea of implementing properties and requirements was based on statisti- 
cal observations showing extensive usage of special constructs. Introduction of 
these techniques has a strong influence on the shortening of reasoning in many 
situations, which is immediately reflected in the maintenance of the MML. 

However, the distinction between the function of properties and requirements 
is not always clear. In some cases, it is hard to decide which of these techniques 
is the best implementation. Requirements are much more flexible, but on the 
other hand, properties are a regular language construct and are not so system 
dependent. Every Mizar user can decide whether or not to use properties for 
newly created definitions while a new requirements directive yields a partial 
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reimplementation of the system. Moreover, some of the features currently imple- 
mented as requirements could be transformed into some kind of properties. In 
particular, it concerns the properties of neutral elements as described e.g. in 3.2. 
There is still discussion on what would be the best syntax for such a neutrality 
property. 

We believe that the techniques worked out in the process of implementing 
requirements ARITHM (cf. 3.6) can also be applied more generally. It appears 
suitable to enable automation of reasonings concerning arbitrary ring opera- 
tions, or to implement the highly desirable associativity property for func- 
tors. Another scope of our interest, following the authors’ requests, is e.g. the 
implementation of transitivity and antisymmetry for predicates. 
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Abstract. Mathematical expressions are pieces of structured informa- 
tion that could beneht from direct-manipulation approaches for docu- 
ment authoring. Yet, not only there is disagreement on the behaviors 
of authoring tools, but also these behaviors are often ill-designed and 
poorly implemented. This situation leads to dissatisfaction amid users 
who prefer more classical editing approaches. 

In this paper we compare the behaviors of several state-of-the-art 
editors for mathematical content and we try to synthesize a set of rules 
and principles to make the authoring experience pleasant and effective. 



1 Introduction 

Direct-manipulation editors for mathematical content allow an author to edit in 
place a mathematical formula as this is formatted and displayed on the screen 
in its traditional notation. Editing and displaying occur simultaneously and the 
formula is reformatted at every modification. These editors are usually character- 
ized by the fact that they work on a structured representation of the document, 
hence they fall in the category of model-based editors. 

Despite their aim of being “friendlier” , direct-manipulation editors turn out 
to be rather unattractive to use for both unexperienced and advanced users since 
they suffer from severe usability problems. In fact, they are more challenging 
to design: the use of a structured model requires the editor to implement some 
kind of incremental parsing meaning that user actions are mapped on non-trivial 
operations on the model. At the same time, part of the information about the 
model structure is not displayed in order to reduce the user’s awareness of the 
model and to provide a familiar, lightweight presentation. We claim that these 
are not sufficient reasons that prevent the design of a direct-manipulation editor 
with good, effective usability [9, 1]. 

While we do not aim to describe the behavior of the perfect model-based 
editor for mathematical content, we can at least try to highlight the deficiencies 
in the existing tools. The goal is to synthesize a set of principles inspired by 
successful text-based editors and common usability guidelines and to provide a 
qualitative evaluation of the examined math editors on these bases. 
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The structure of the paper is as follows: in Section 2 we describe the dynamics 
of a number of direct-manipulation editors for mathematics. We enrich the prose 
of the descriptions with a graphical notation whose purpose is to capture the 
dynamic behavior of the editors on a static medium like the paper. In Section 3 
we do a little step back to the world of text editors, for which a tighter and 
more standardized set of rules and behaviors have emerged over the years. The 
analysis of these rules will be the starting point for our proposal in Section 4, 
where we try to classify distinct and possibly orthogonal aspects of model-based 
editors, in particular editors for mathematics, and list some intuitive guidelines 
for their development. We conclude in Section 5 with a comparison of the tested 
editors. 



2 Behaviors 

We began our analysis by trying out a number of currently available editors to 
understand how behaviors were implemented and what rationales were behind 
the choices. The following is the list of the products that we have tried. Some 
of them are just software components whose only purpose is to display and edit 
mathematical formulas, others are more complex applications for which editing 
mathematics is only an auxiliary (sometimes indispensable) functionality: 

1. Amaya version 8.2. We& pa^e.' http://www.w3.org/Amaya/ 

2. PrameMaker by Adobe, version 7. 

Web page: http://www.adobe.com/products/framemaker/main.html 

3. MathType by Design Science, version 5.2. 

Webpage'-http : //www . mathtype . com/ en/products/mathtype/, see also[13] . 

4. Scientific Workplace by MacKichan Software, version 5 
Web page: http : / /www . mackichan . com/products/ swp . html 

5. LyX version 1.3.4. Web page: http://www.lyx.org/, see also [6]. 

6. Mathematica by Wolfram, version 5. 

Web page: http : //www. wolfram. com/products/mathematica/index .html 

7. T^jXmacs version 1.0.1.23. lTe& pa^e.' http://www.texmacs.org/ 

The products have been chosen to represent the current state-of-the-art in 
both commercial and freely available software. 

2.1 Models and Edit Points 

One of the characteristics of these editors is that they are model- oriented rather 
than text- oriented. By this we mean that the internal representation of the edited 
document is structured and the editing commands work directly on the internal 
representation. This is the main source of problems because editing operations 
(including movements) are performed on a non-linear data structure that, once 
displayed, may convey only partially or approximately the overall information 
it represents. For example, if the model represents the sum of two entities as a 
binary node, because of the associativity law of addition a sum like x -\- y -\- z 
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may be displayed with no parentheses, thus concealing the actual structure which 
may be either one of {x + y) + z or x + {y + z). 

Because of the structured nature of the internal application model, the infor- 
mation that is necessary for unambiguously specifying the point where the next 
editing operation will occur is made of: 

— the node of the model pointed to; 

— the index, also called insertion point, indicating the sub-part of the node 
where something has to be inserted. Terminal (or leaf) model nodes, which 
usually represent identifiers, numbers, and, more generally, sequences of char- 
acters, typically have as many indexes as the number of characters plus one. 
Non-terminal (or internal) model nodes have a number of valid indexes which 
may vary depending on the structure of the model. 

We call the combination of these two entities edit point} Most editors give a 
visual feedback for both entities. The index is typically presented by a vertical 
bar called caret. The node presentation, called focus, ranges from a horizontal line 
spanning the node’s horizontal extent on the view, a prolongated caret spanning 
the node’s vertical extent on the view, a solid or dashed rectangle surrounding 
the node, and so on. Some editors like amaya have no visual feedback for the 
focus at all, others like lyx and texmacs emphasize all the elements from the root 
of the internal application model to the focus, amaya and texmacs give additional 
feedback at the bottom of the editing window by providing the stack of node 
names from the root of the document down to the edit point. 

In this paper we represent the caret with ^ or ^symbols and we underline the 
focused node. For example, ^ represents a focused token node whose content 
are the two letters ‘s’ and ‘n’, with the caret sitting in between. An insertion of 
the character ‘i’ would change the node to s(n. 



2.2 Presentation of Missing Information 

Model-based editors are usually constrained by the structure of the model. For 
example, a node of the model representing a binary operator may be required 
to have two child nodes, one for each operand. However the sequential nature 
of the editing process prevents the document to be well- formed at all times. 
Missing parts of the document that are expected to be filled in are called slots. 
The visual feedback of slots may vary, ranging from question marks on a reverse 
background in framemaker, to solid or dashed rectangles in mathtype, mathematica, 
and lyx to nothing at all in texmacs. 



2.3 Basic Moves 

Since the purpose of editing is to change a document and since the operations 
that change the document are performed at edit points, one of the main concerns 

The use of the term “point” dates back to the TECO editor as documented in [12]. 



1 
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Table 1. Traversal of a horizontal group of elements 





amaya 


framemaker, mathtype, mathematica, lyx, scien- 
tific workplace, texmacs 






tP + ° 


(right^ 




qr+° 












n + a 




°+tP 






° + qr 




(Eeft)* 


reverse 


reverse 



is how to reach edit points. We will devote this section to a comparison of the 
various strategies adopted by the editors. In order to do so, we present a series of 
tables, each of them devoted to a common mathematical construct. The tables 
show the movements of the caret and possibly of the focus as the user requests 
a sequence of actions. Actions are triggered by keystrokes: (left) , (mcia . (ug, (down) 
represent the basic cursor movement keys. In the tables time flows from top 
to bottom, the keystrokes are shown in the leftmost column of the diagram 
whereas the cells in the other columns show the state of the various editors after 
the action associated with that keystroke has been executed. We denote with 
the word “reverse” sequences of states that mirror the corresponding states for 
the opposite action. We denote arbitrary subexpressions with the symbol □ and 
assume that they are traversed with a single action. 

Rows. We start with a simple list of identifiers separated by operators (Table 1). 
Even for this simple formula editors may have different behaviors. The amaya 
editor advances the caret by a little step between identifiers and operators, thus 
moving from the end of a node in the model to the beginning of the next one. This 
gives visual feedback about the focused node, which is assumed to be the one the 
caret is closest to, but the user has the impression of a slowed-down traversal. 
Conversely, the other editors provide a natural traversal behavior where one 
action corresponds to one step. 

Scripts. Next we examine the scripting construct (Table 2), which is used for 
exponents, indices, integration limits, and so on. From a geometrical point of 
view this is the construct where bi-dimensional layout starts playing an im- 
portant role since scripts are vertically shifted with respect to the main base- 
line. 

The observed behavioral variants include: full traversal of the scripts (amaya 
and mathematica), deterministic traversal of a subset of the scripts (mathtype 
and scientific workplace), skipping of the scripts unless an explicit action is re- 
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Table 2. Traversal of scripts 
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mathematica 
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(left) 
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always 
(see text) 


reverse 
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quested (framemaker and lyx, note however that lyx traverses one more edit point). 
A particularly original behavior is observed in the texmacs editor, in which only 
one of the two scripts is traversed: the script that was visited last in the previ- 
ous traversal is the one to be visited during the next traversal, framemaker is also 
bizarre: the traversal is reversible if the state reached by (right) moves is □□ +p, 
but it is not reversible if the reached state is □□ -I- 

The (uD and (down) keys have very different associated behaviors: from no-ops 
to switching between subscripts and superscripts, to jumping to the beginning 
or the end of the whole construct. 

Radicals. Roots (Table 3) can be thought as a variant of the script construct, 
from both semantical and notational points of view. Still they present very dif- 
ferent behaviors if compared to scripts. Again the traversals range from partial 
to full navigation of the subparts, and again framemaker presents an odd behav- 
ior that is not reversible in some cases. The mathtype editor skips the index and 
provides no way of accessing it except by moving the caret on a different line 
and finding an edit point such that a vertical movement in the opposite direction 
causes the caret to hit the index. 

Fractions. In Table 4 we traverse fractions. This construct is characterized by 
a clear vertical layout which is completely orthogonal to the baseline. Here too 
the behaviors are very different, although slightly less bizarre, probably because 
there is no horizontal component in the displacement of the subparts. Again we 
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Table 3. Traversal of roots 
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Table 4. Traversal of fractions 
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recognize full traversals in amaya and mathematica, partial deterministic traversal 
in lyx, mathtype and scientific workplace (lyx has a different traversal in the opposite 
direction), inner traversal caused by explicit user action in framemaker, and par- 
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tial, visited-last-dependent traversals in texmacs. In all cases ® and cause 
the caret to be moved from the numerator to the denominator or vice versa. 



Table 5. Traversal of matrices 




Matrices. Finally we examine a truly bidimensional mathematical construct in 
Table 5, which shows the traversal of possibly fenced matrices. In framemaker the 
construct is skipped unless the user triggers the (down ) action explicitly, in which 
case a full traversal is performed. 

2.4 Special Moves 

Aside basic moves, most editors provide a behavior associated with the (IaD key 
that causes the edit point to jump across parts of the model following varying 
strategies. Among the observed ones there are: cycling the empty slots of the 
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whole formula (framemaker, mathematica and mathtype); moving to the next slot 
(lyx, there is no inverse action); cycling the child nodes of the focused node 
(scientific workplace), amaya and texmacs have no behavior associated with the {taD 
key. 

Regarding (up) and (dowD moves, they do not always behave geometrically. For 
example, in framemaker the (down) key has the effect of moving the edit point 
down the structure to the first child of the node being edited and the (up) key 
has the effect of moving the the edit point up the structure to the parent of the 
node being edited. In mathematica (iD and (down) have a context-sensitive behavior 
which is not always geometrical. In lyx the behavior is partially geometrical but 
constrained by the model structure. For example, moving from a superscript 
down towards the subscript (or from a subscript up towards the superscript) 
causes the edit point to be placed just after the base element. 

2.5 Editing Actions 

Constrained Versus Unconstrained Editing. Different editors have different con- 
cepts of a well-formed formula and consequently they constrain editing opera- 
tions in very different ways. On one end is framemaker which tries to keep the 
formula semantically meaningful. So, for example, the user is prevented from 
entering a formula like a -I- + 6 and parentheses must always be balanced, math- 
ematica sometimes provides different variants of a construct, one algebraic and 
one typographical, that have different constraints. Other editors like amaya and 
lyx have a looser concept of well-formed formula and, apart from the constraints 
imposed by the typographical structure of the formula, they allow for much 
more freedom in the editing process. In mathtype editing is almost totally un- 
constrained, for instance it is possible to have scripts not associated with a base 
element . 

Templates and Overlays. These concepts represent two similar ways of assisting 
the author in changing the structure of the document. Templates are partial 
formulas with empty slots. The user can insert a template in a certain point 
of the document, typically at the current edit point or, if the editor allows it, 
in place of a previously selected part of the document. Overlays are special 
templates in which one designated slot is filled with the document part that is 
referenced by the edit point or that is selected at the time the overlay is inserted. 
All of the tested editors implement one or the other or, more frequently, both 
templates and overlays. 

Delete Commands. Delete commands for model-based editors are particularly 
delicate because the edit point may refer to internal nodes of the model. In 
the particular case of fractions. Table 6 shows some of the observed behaviors 
associated with the im) key (delete to the left of the caret): entering the node, 
similar to a (left) move (mathematica and texmacs); entering the node and deleting 
recursively (amaya); deleting the whole node in one shot (framemaker and lyx); 
selecting the node and deleting it only if the user repeats the action (mathtype, 
in the table the selected fraction is shown inside a box). 




310 



L. Padovani and R. Solmi 



Table 6. Different behaviors associated with the deletion of fractions 
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3 Learning from Text Editors 

Although a plain text document can be seen as a monodimensional entity (a 
stream of characters), word processors usually introduce some structure by al- 
lowing parts of the text to be annotated with style information. So, albeit to a 
limited extent, even text editors are based on a somehow structured model. In 
their case, however, there happens to be a much stronger convergence of behav- 
iors associated with user actions. We can characterize such behaviors, at least 
with respect to the kind of actions we have been examining so far, as follows: 

— basic steps on the document view can be achieved by means of basic user 
actions (basic = one keystroke). The emphasis is on the view rather than on 
the model. For example the behaviors associated with the and Sowa keys 
move the edit point to another one (on a different line) that is not adjacent 
with respect to model structure. 

— basic operations like insert or delete actions act on the smallest entity in the 
proximity of the edit point; 

— when provided, movements and operations on the document model (move- 
ment from a word to the following or preceding ones, the deletion of a whole 
line, and so on) require the user to perform dedicated actions; 

— there are no fake moves: each user action clearly corresponds to a definite 
movement of the caret in the view. The user is never required to perform 
extra movements to get across different elements on the model (e.g. entering 
a part of text which has a different style requires no extra moves if compared 
to continuing moving on a paragraph with the same style); 

— movements are geometrically reversible: in any position except for the doc- 
ument border, one (left) nullifies exactly one (right) , one (uB nullifies exactly 
one (Bowl). Modern editors have often preferred reversibility of actions over 
simpler geometrical movements: for example moving from the end of a line 
to a shorter one causes a horizontal displacement of the caret, however a 
reverse move restores the caret location. 

Editors providing different styles have to face the problem of edit point clash- 
ing. When the caret is placed between two characters having different associated 
styles, which style is taken for the next inserted character? Some editors try to 
give the caret a different appearance (like drawing a slanted vertical bar instead 
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of a straight one, or drawing a caret which is as tall as the current font size) 
but this is not always enough to disambiguate the focus in general. Most edi- 
tors implement a deterministic rule like “the style of the character preceding the 
caret is taken” which works well in all cases but a few rare exceptions. In editors 
for mathematical content this solution might be impractical because the model 
structure is more complex and plays a much more important role. 



4 Analysis and Proposal 

Although the two kinds of editors, for structured mathematical content and for 
plain text, are conceptually very different, we believe that the set of behaviors 
they implement could and should share a large common ground. In this respect, 
the current state-of-the-art math editors are certainly unsatisfactory and this 
claim is supported by the following observations: 

— the application model is exposed to the user: while working at the model 
level simplifies the implementation of the editor, it also forces a view of the 
document which often does not match the user’s mental image of the math- 
ematical formula being edited. Geometric movements, editing operations, 
selections should not be constrained by the model unless the user explicitly 
requests so; 

— model-oriented and geometric navigation modes are mixed: for example, the 
(right) keystroke sometimes triggers a geometric move and sometimes it trig- 
gers a movement on the model. In other cases, see for example the framemaker 
editor, (right ) / (left) always behave geometrically, but (up / (down) correspond to 
movements on the model; 

~ important feedback, like the placement of empty slots in amaya and texmacs, 
is sometimes missing; 

— there is excess of useless feedback. There is no point in showing a focus if it 
serves no purposes in terms of feedback (moreover the focus is very model 
dependent by definition). Even less useful, and actually confusing, is showing 
the structure of the document in places that are not directly related to the 
edit point (see the texmacs editor); 

— unexpected or ambiguous behaviors lack suitable feedback: operations that 
are uncommon in text editors (like deletion of a complex model node) should 
be carefully implemented (see deletion in framemaker and lyx); 

~ some actions are non-deterministic: they depend on a state of the document 
which is not made explicit by any form of feedback; 

— simple movements are not always reversible; 

— there is lack of dedicated views for model-oriented navigation and editing. 

What follows is our proposal for a more uniform editing behavior. 

Edit Points. It is fundamental for the application to provide effective visual 
feedback of the caret. The caret should give the impression of actual movement, 
while the focus should be displayed only if it helps disambiguating the context 
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where actions take place. In fact the focus may be misleading when the editor 
implements incremental parsing rules that override the focus position depending 
on the requested actions. For example, upon insertion of the digit 2 from either 
one of the states y- and y- the editor might go into the state 1^. In this case 
the focus prior to the insertion does not necessarily indicates the model node 
affected by the operation. 

Slots. While an empty slot occupied by the caret might need no visual feedback, 
parts of the document that are missing should be clearly identifiable and easily 
reachable. 

It is often convenient to provide a quick way for moving across the slots 
within the document (or within a smaller scope such as a single formula) . This 
functionality is typically accessed by the (|a 1 key (and ssfA + (taD for moving 
in the opposite direction). As there is quite general agreement on this behavior 
among the current editors, there are no particular principles to be listed except 
for reversibility. The order in which the slots are visited is also of secondary 
importance as the user expects the caret to jump anyway and the number of 
slots, which is typically very limited, makes them all reachable very quickly. 

Geometric Navigation. This should be the default navigation mode as it is con- 
sistent with the “what-you-see-is-what-you-get” principle that the user edits 
what she sees. More precisely, the user should be allowed to traverse the docu- 
ment in such a way that basic move actions cause an actual, yet basic, movement 
of the caret in the requested direction. As formulas often occur inside text, where 
geometric movements are commonly accepted, these rules should apply within 
the formulas as well in order to guarantee adequate consistency. More specifically: 

— the caret is moved to the geometrically closest and deepmost edit point in 
the direction of the movement. The notion of “direction” we are referring to 
here is necessarily blurred, as in mathematical notation related parts (like 
a base and its associated script) are often placed with both horizontal and 
vertical displacements; 

— in case of ambiguities (edit points at different locations that are equally 
distant and equally deep) the editor should behave in a deterministic way. 
The model structure can be used for resolving such ambiguities; 

— the movement should be perceived by the user as worthwhile, the user should 
not be required to move across entities she has not inserted explicitly; 

— movements of the caret on the view should be reversible whenever possible. 

Determinism is important for avoiding the introduction of a state in the user’s 
mental image of the document ( “which node have I visited last?” ) . 

The geometric navigation mode does not guarantee in general that all the 
available edit points are traversed. The principle that prefers deeper edit points 
ensures that the caret is moved on a position where operations have the less 
disruptive effect on the structure of the model. 

Content Navigation. As text editors normally allow the navigation at some 
larger granularity (like the granularity of words and paragraphs) we may expect 
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a similar functionality for editors of mathematical formulas. An analogous con- 
cept of higher-level entity for mathematics may be that of subexpression, or 
subformula. Unfortunately, this concept is so broad (and often fuzzy) that it 
cannot be used for the implementation of a generally useful navigation mode. 

It is however possible to provide simple navigation modes that are based on 
a smaller higher granularity, like that of tokens, with the purpose of speeding 
up document navigation. The principles of geometric navigation should hold at 
this level as well. 

Model Navigation. This navigation mode is indispensable for reaching edit points 
that are not accessible using the geometric navigation mode alone. However, we 
regard this as a far less frequent navigation mode, especially because it requires 
the user to have a fairly clear understanding of the model structure used by the 
application. For these reasons we strongly advocate the use of one or more ded- 
icated views that enable model-oriented navigation and editing functionalities. 
This approach is followed by so called two- view editors, such as [5, 7, 4, 10] and 
also by some modern Integrated Development Environments^ where a special 
view is provided to show a structured outline of the edited documents. 

Selection. The basic selection mode should allow for the maximum flexibility. In 
particular, it should be possible to select parts of the edited document that have 
no semantic meaning or that form incomplete subexpressions, the same way as 
movements and editing should be unconstrained as much as possible. Because 
of the complex bidimensional layout of mathematical formulas, it should be 
possible to refine a selection in multiple, discrete steps, rather than allowing 
only a one-shot action of the user. 

Notwithstanding this, it is not excluded the possibility of using the applica- 
tion model for enabling constrained forms of selection even on the classical view. 
For instance, it may be important to notify the user that the selection she has 
made does not entirely cover a valid^ model subpart and that subsequent paste 
operations might fail for this reason. 

Editing. Depending on the application and on the model structure, the range of 
editing operations available at one specific edit point may vary significantly. In 
the tested editors operations mostly work at the bottommost level (the leaves 
of the model), while operations on the model structure are limited to selection, 
cut-and-paste, deletion. However, as we have already discussed in the paragraph 
regarding edit points in this section, editors may implement incremental pars- 
ing rules such that even simple user actions cause deep rearrangements in the 
structure of the document (similar approaches are presented in [15, 14,8]). This 
way, the editing environment would provide for improved flexibility thus reduc- 
ing training time and discomfort while keeping the actual structure of the model 
hidden from the user. 



^ See for instance Eclipse, http://www.eclipse.org 
® The notion of validity is obviously application-dependent. 
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5 Concluding Remarks 

It was during the implementation of a model-based editor for mathematical doc- 
uments that we gradually realized the countless and subtle difficulties that this 
kind of application underlies. When we turned our attention to existing editing 
tool, hoping to grab some knowledge about the implemented behaviors and about 
the user needs and expectations, it was surprising to find out that no two editors 
shared exactly the same behavior on every aspect, and that several choices made 
by implementors seemed supported by no solid motivations. The amazing range 
of possibilities cannot be justified merely on the basis that different editors have 
different underlying document models. Although such differences do exist, the 
editors should still strive for providing a comfortable and familiar environment. 

Precise descriptions of the dynamics of model-based editors are rare in the 
bibliography. Incidentally, none of the tested editors provides comprehensive 
documentation about their behavior, probably because the behavior cannot be 
easily described on a static medium like the paper. A few informal attempts in 
this direction can be found in [15], where a token-oriented model is proposed, 
and in [8]. Barfield [2] has tried to classify tree-editing operations and some of 
his ideas influenced the navigation modes in Section 4. 

Comparisons of document editors have usually the aim of measuring their 
effectiveness in terms of rate of accomplished tasks, average number of errors, 
and so on. In the case of text editors, most of the work was carried out during the 
eighties. Of particular relevance are Roberts et al. [11] and Borenstein [3]. Some 
interesting statistics about document editors can also be found in Whiteside 
et al. [16], where the importance of movement actions is highlighted. This is 
one of the reasons why we have devoted so much effort in understanding and 
analyzing geometric moves in the examined editors. It is reasonable to assume 
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that a similar suite of tests can be prepared for editors for mathematical content, 
but to the best of our knowledge no formal comparison has been developed so 
far. 

At last, we could not refrain from summarizing the usability of the tested 
editors. For each of the features investigated in this paper we have given a 
measure of usability of its implementation. In Table 7 an empty cell means “not 
implemented” or “poor support”, a o symbol means “partial support” and a 
• symbol means “good support” . We have also given a rough measure of the 
complexity of the model used by the editors. Intuitively, the more complex the 
model the more difficult it is to implement behaviors that respect our proposals. 
The results are clearly subjective and approximate. In fact, in many cases we 
could only guess about the model structure adopted by the editor. However, the 
table provides us with a rather strong feeling that direct-manipulation editors 
can be significantly improved, and that this might justify their unpopularity 
among both unexperienced and expert users. 
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Abstract. A major obstacle for bridging the gap between textbook 
mathematics and formalising it on a computer is the problem how to 
adequately capture the intuition inherent in the mathematical notation 
when formalising mathematical concepts. While logic is an excellent tool 
to represent certain mathematical concepts it often fails to retain all the 
information implicitly given in the representation of some mathematical 
objects. In this paper we concern ourselves with matrices, whose rep- 
resentation can be particularly rich in implicit information. We analyse 
different types of matrices and present a mechanism that can represent 
them very close to their textbook style appearance and captures the in- 
formation contained in this representation but that nevertheless allows 
for their compilation into a formal logical framework. This firstly allows 
for a more human-oriented interface and secondly enables efficient rea- 
soning with matrices. 



1 Introduction 

A big challenge for formalising mathematics on computers is still to choose a rep- 
resentation that is on the one hand close to that in mathematical textbooks and 
on the other hand sufficiently formal in order to perform formal reasoning. While 
there has been much work on intermediate representations via a ‘mathematical 
vernacular’ [3, 12, 5], most of this work concentrates on representing mathemati- 
cal proofs in a way that closely resembles the human reasoning style. Only little 
attention has been paid to an adequate representation of concrete mathematical 
objects, which captures all the information and intuition that comes along with 
their particular notation. Logicians are typically happy with the fact that such 
concepts can be represented in some way, whereas users of a formal system are 
more concerned with the question, how to represent a concept and how much ef- 
fort is necessary to represent it. Depending on the purpose of the representation 
it is also important how easy it is to work with it. 

In this paper we examine one particular type of mathematical objects, namely 
matrices. Let us first take a closer look how the matrix concept is introduced in 
a mathematical textbook. Lang [8, p.441] writes: 
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“By an TO X n matrix in R one means a doubly indexed family of elements 
of R, (ttij), (i = 1, . . . , TO and j = 1, . . . , n), usually written in the form 



On • • • ain 

^ml ’ ’ ’ ^mn 

We call the elements the coefficients or components of the matrix.” 

Mathematicians do not work with the definition alone. The definition already 
introduces the representation as a rectangular form in which the elements of a 
matrix are ordered with respect to their indices. Matrices can be viewed as 
collections of row or column vectors, as block matrices, and various types of 
ellipses are used to describe the form of a matrix. The different representations 
are used to make the relevant information directly accessible and ease reasoning. 

Depending on the exact logical language, one would consider a matrix as a tu- 
ple consisting of a double indexed function, number of rows, number of columns, 
and the underlying ring. And opposed to mathematics, one has to stick to this 
definition during all proofs. The (logical) view that a matrix is a tuple, which 
mainly bears aspects of a function, is not adequate from a mathematical point of 
view. If we look at a concrete matrix such as a 2 x 2 matrix containing only the 
zero element this matrix Z is a constant. This means in particular that for any 
matrix M, the product M ■ Z is equal to Z without the necessity to do reason- 
ing about tuples and lambda expression. This is analogous to the relationship 
between the formal logical and mathematical view of the natural number four, 
which logically is the ground term s(s(s(s(0)))), while mathematically it is the 
constant symbol 4. 

In this paper we show how to abstract from the functional representation 
of concrete matrices and how to attach structural information for matrices to 
the formal representation by so-called annotated constants. The structural in- 
formation can be used for reasoning, which simplifies proof construction since 
some of the reasoning steps can be expressed as computations. The connection 
to the formal content allows the verification of the abstract proof steps in the 
underlying logical calculus. 

In the next section we will have a closer look at different types of matrices 
that we want to be able to represent. In section 3 we will introduce annotated 
constants as an intermediate representation for mathematical objects. In sec- 
tion 4 we will discuss how concrete matrices, block matrices and ellipses can 
be represented and manipulated as annotated constants. We conclude with a 
discussion of related and future work in section 5. 



2 Matrices — Examples 

In this section we give an overview of some important cases of matrices and their 
representations as they appear in algebra books (e.g. [8,6]). We do not intend 
to give an exhaustive overview. However, we believe that the cases covered here 
will allow for generalisations and adaptations to others. We discuss some of the 
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representational issues, for which we propose solutions in the subsequent sections 
of the paper. 

2.1 Concrete Matrices 

A matrix is a finite set of entries arranged in a rectangular grid of rows and 
columns. The number of rows and columns of a matrix is often called the size 
of that matrix. The entries of a matrix are usually elements belonging to some 
algebraic field or ring. Matrices often occur in a very concrete form. That is, the 
exact number of rows and columns as well as the single entries are given. An 
example is the following 2 x 3-matrix: 

Matrices of this form are fairly easy to represent and handle electronically. 
They can simply be linearised into a list of rows, which is indeed the standard 
input representation of matrices for most mathematical software, such as com- 
puter algebra systems. Since both the size of the matrix is determined and all 
the elements are given and of a specific type, manipulations of the matrix and 
computations with the matrix can be efficiently performed, even if the concrete 
numbers are replaced by indeterminates such as a, 5, c. 

While concrete matrices often occur in many engineering disciplines, pure 
mathematics goes normally beyond concrete sizes, but will speak of matrices in 
a more generalised fashion. 

2.2 Block Matrices 

Block matrices are matrices of fixed sizes, typically 2 x 2 or 3 x 3, whose elements 
consist of rectangular blocks of elements of not necessarily determined size. Thus, 
block matrices are in effect shorthand for much larger structures, whose internal 
format can be captured in a particular pattern of blocks. Consider, for instance, 
the general matrix of size (n -I- 1) x (n -I- 1) given as 




in which a yf 0 is a ring element (scalar), 0 is the zero vector of size n, is the 
transpose of an arbitrary vector v of size n, and A is a matrix of size n x n. 

A block matrix can be emulated with a concrete matrix by regarding its 
elements as matrices themselves. This can be achieved by identifying, scalars 
with 1x1 matrices, vectors with n x 1 matrices, and transposed vectors with 
1 X n matrices. While this enables the use of the techniques available for concrete 
matrices to input and represent block matrices, manipulating block matrices is 
not as straightforward. Since the elements do no longer belong to the same 
algebraic ring (or indeed to any ring), computations can only be carried out 
with respect to a restricted set of axioms. In particular, one has to generally 
forgo commutativity when computing with the single blocks. Again this can be 
simulated to a certain extend. For instance, the inverse of the above matrix 
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can be computed by using a computer algebra system that can deal with non- 
commutativity, as demonstrated in section 4.2. Computations concerning two 
block matrices, such as matrix addition or multiplication can be simulated as 
well. However care has to be taken that the sizes of the blocks are compatible. 



2.3 Ellipses 



While block matrices can capture simple patterns in a matrix in an abstract 
way, more complex patterns in generalised matrices are usually described using 
ellipses. Consider for instance the definition of the following matrix A: 



A = 



I' an b 

0 

Vo 



.. 6 \ 

■. b 

0 ajin / 



The representation stands for an infinite class of n x n matrices such that we 
have a diagonal with elements an, 1 < i < n, all elements below the diagonal 
are zero, while the elements above the diagonal are all b. A matrix of this form 
is usually called an upper triangle matrix. 

In the context of matrices we can distinguish essentially two types of ellipses: 

1. Ellipses denoting an arbitrary but fixed number of occurrences of the same 
element, such as in (0 • • • 0). 

2. Ellipses representing a finite number of similar elements that are enumerated 
with respect to a given index set (oi • • • a„)^. 



Both types of ellipses are primarily placeholders for a finite set of elements 
that are either directly given (1) or can be inferred given the index set (2). 

Another important feature of ellipses in the context of matrices are their 
orientation. While for most mathematical objects, such as sets or vectors, ellipses 
can occur in exactly one possible orientation, in two-dimensional objects such as 
matrices we can distinguish three different orientations: horizontal, vertical, and 
diagonal. Thereby ellipses are not only placeholders for single rows, columns or 
diagonals but a combination of ellipses together can determine the composition 
of a whole area within the matrix. For example the interaction of the diagonal, 
horizontal and vertical ellipses between the three Os in A determines that the 
whole area underneath the main diagonal defaults to 0. 

Matrices with ellipses are well suited for manipulation and reasoning at an 
intuitive abstract level. However, already their mere representation poses some 
problems. While they can be linearised with some effort, a two-dimensional rep- 
resentation of the object is preferable, as this eases to determine the actual 
meaning of the occurring ellipses. It is even more challenging to mechanise ab- 
stract reasoning or abstract computations on matrices with ellipses. 



^ Here the notion of an index set is not necessarily restricted to being only a set of 
indices for a family of terms, but we also use it with a more general meaning of 
enumerating a sequence of elements as for instance in the vector containing the first 
n powers of a, {a} ■ ■ ■ a’^). 
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2.4 Generalised Matrices 

While ellipses already provide a powerful tool to express matrices in a very 
general form by specifying a large number of possible patterns, one sometimes 
wants to be even more general than that. Consider for instance the following 
definition of matrix B: 



B = 


( ail * 
0 


• • • * ^ 


. Also written as: | 


1' ail 

r\ 






Iv 0 


'k 

0 ^nn / 




^0 


^nn / 



Matrix B is very similar to A above, with the one exception that the elements 
above the main diagonal are now arbitrary, indicated by *, rather than b. This is 
a further generalisation as B now describes an upper triangle matrix of variable 
sizes n X n, where we are only interested in the elements of the main diagonal 
an, I < i < n, but we don’t care about the elements above the diagonal. While 
such a matrix can be represented with the same representational tools as the 
matrix A above, it will be more difficult to deal with when we actually want to 
compute or reason with it. 

In the following we shall describe how we can handle concrete matrices, block 
matrices, and ellipses. In order to extend our approach to cover generalised 
matrices as well, we would need to handle “don’t care” symbols, in addition. We 
do not go into this question in this paper. 



3 Intermediate Representation — Annotated Constants 

In this section we present the concept of annotated constants, a mechanism that 
provides a representational layer that can both capture the properties of the 
intuitive mathematical representation of objects, as well as connect these objects 
to their corresponding representation in a formal logic framework. Annotated 
constants are implemented in the Omega system [10] and therefore the logical 
framework is Omega’s simply typed lambda calculus (cf. [1]). We have first 
introduced annotated constants in [11] in the context of mathematical objects, 
such as numbers, lists, and permutations. For the sake of clarity we explain the 
idea in the following using the much simpler example of finite sets. 

Let us assume a logical language and a ground term t in this language. Let c 
be a constant symbol with c = t. An annotated constant is then a triple (c, t, a), 
in which a is the annotation. The annotation a is any object (making use of 
an arbitrary data structure) from which c and t can be reconstructed. Think 
of c as the name of the object, t as the representation within logic, and a as a 
representation of the object outside logic. 

Finite Sets: Finite sets have a special notation in the mathematical vernacular, 
for example, the set consisting of the three elements a, b, and c is denoted by 
{a, &, c}. We can define this by giving the set a name, e.g.. A, and a definition 
in logic as a ground term. Important knowledge about sets with which it is 
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appropriate to reason efficiently is: sets are equal if they contain the same ele- 
ments regardless of their order, or the union of two sets consists of the elements 
which are a member of one of the sets and so on. This type of set manipulation 
has not so much to do with logical reasoning as it has with computation. The 
union of two sets, for instance, can be very efficiently computed and should not 
be part of the process of search for a proof. 

Annotated constants for finite sets are defined with the attributes 

Annotation for Finite Sets: The data structure of sets of the underlying pro- 
gramming language is used as annotation and the elements of the set are 
restricted to closed terms, e.g., the set containing the three constants a, b, 
and c in the concrete example. 

Constant Symbol: We give the set a name such as A. Even more appropriate 
for our purpose is to generate an identifier from a duplicate free ordering of 
the elements of the set, for the example A^a,b,c}- 
Definition: The definition of the set corresponds to a lambda term in higher- 
order logic, e.g., Xx.{x=a V x=b\J x=c). In order to normalise such terms it 
is useful to order the elements of the set, that is, we wouldn’t write the term 
as \x.{x=b V x=a V x=c). Since the annotation has to represent the object 
completely the formal definition can be constructed from the annotation. 

The basic functionality for handling annotated constants is implemented on 
the term level of the Omega system. In first approximation, an annotated con- 
stant is a constant with a definition and has the type of its defining term t. 
As such it could be replaced by its defining term during the proof or when ex- 
panding the proof to check formal correctness. Typically, this is not done, but 
annotated constants are manipulated via their annotations. The defining term 
of an annotated term is used only when necessary. 

The manipulation of operations and verification of properties is realised as 
procedural annotations to functions and predicates. A procedural annotation is 
a triple (/, p,T), where / is a function or predicate of the logical language, p 
is a procedure of the underlying programming language with the same number 
of arguments as / and T is a specification (or tactic) for the construction of 
a formal proof for the manipulation performed by p. The procedure p checks 
its arguments, performs the simplification, and returns a simplified constant or 
term together with possible conditions for this operation. 

For example, the procedure for the union of concrete sets {a, &}U{c, d} checks 
whether the arguments are annotated constants for concrete sets, and returns 
the annotated constant which has the concatenation of {a, 6} and {c,d} as an- 
notation. Analogously the property {1, 2, 3} C Z holds, when all elements of the 
annotation of the set are constants which have as annotation an integer as data 
structure. 

The proof specification T is used to formally justify the performed step. 
Thereby an annotated constant is expanded to its formal definition and the 
computation is reconstructed by tactic and theorem applications. This expansion 
will be done only when a low level formal proof is required, certainly not during 
proof search. 
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What Are the Advantages of Using Annotated Constants? 

Firstly, annotated constants provide an intermediate representation layer be- 
tween the intuitive mathematical vernacular and a formal system. With anno- 
tated constants it is possible to abstract from the formal introduction of objects, 
allow the identification of certain classes of objects and enable the access of rele- 
vant knowledge about an object directly. Annotations can be translated into full 
formal logic expressions when necessary, but make it possible to work and reason 
with mathematical objects in a style that abstracts from the formal construction. 

Secondly, annotations allow for user friendly input and output facilities. We 
extended Omega’s input language to provide a markup for an annotated con- 
stant to indicate the type of the object it represents. For each kind of annotated 
constant the term parser is extended by an additional function, which parses 
annotations and transforms these annotations into an internal representation. 
During parsing additional properties can be checked and errors in the specifica- 
tion can be detected. In this way it is possible to extend syntactic type checking. 
An additional output function for each kind of annotated constant allows to have 
different display forms for presenting formulas to the user. 

Thirdly, procedural annotations enable an efficient manipulation of annotated 
constants. Theses procedures can access information without further analysis 
on (lambda) terms (which define annotated constants formally) and allows to 
compute standard functions and relations very efficiently. These operations and 
properties become a computation on the data structures of annotated constants. 



4 Matrices as Annotated Constants 



In this section we show how annotated constants can be used to implement the 
different representations for matrices presented in section 2. 



4.1 Concrete Matrices 



Concrete matrices of fixed sizes, for example. 



M = 



3 2 7 
1 0 4 



can be represented in higher-order logic as a 4-tuple: (/, 2,4, Z) where / is the 
lambda expression^ 



XiXj. if i 
elseif i 
elseif i 
elseif i 
elseif i 
else 



1 


> 

II 


= 1 


then 


3 


1 


Aj = 


= 2 


then 


2 


1 


Aj = 


= 3 


then 


7 


2 


Aj = 


= 1 


then 


1 


2 


Aj = 


= 2 


then 


0 



4. 



^ The conditional if P then m else n can be defined in higher-order logic by the 
description operator i. The expression iy,S{y) denotes the unique element c such 
that S{c) holds, if such a unique element exists. A conditional can thus be defined 
by ik. {P A {k = m)) V {-^P A (fc = n)), which returns m if P holds, else n (for more 
details see [1]). 
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When we look at the concrete matrix the information connected to this rep- 
resentation is, that the position of all the elements is specified and that the 
number of rows and columns of the matrix are immediately perceivable. When 
we look at the formal representation, then even to access an element at a certain 
position requires reasoning, even non-trivial reasoning when, for example, the 
first condition is given as / XiXj. if P{i,j) then 3 elseif . . . where P{i,j) is some 
equivalent formulation of t = 1 A j = 1. 

Also in order to multiply two concrete matrices, reasoning about the corre- 
sponding lambda expressions is necessary. For instance, the transpose of 
M is 




which can be represented as a 4-tuple (/^,4, 2,Z) where is the function you 
get by swapping the arguments of /, i.e. XjXi rather than XiXj. The product M® 
is a matrix (/ *4 /^, 2, 2, Z), in which the function is computed component 
wise as the sum of products of ring elements, that is, XiXj. if i = 1 A j = 
1 then 3-3-I-2-2-I-7-7 elseif . . ., which requires considerable reasoning to 
arrive at the result. We argue that although this can be done in logic, it is not 
appropriate, analogously as it is not appropriate to compute a product such as 
20 • 15 by reasoning with the definition of • in the constructors 0 and s over the 
natural numbers. 

We therefore define annotated constants for concrete matrices as follows: 

Annotation for Concrete Matrices: The data structure of arrays, where the 
elements are in the logical language and all of them have the same type a. 
All places of the array must be filled with constants of the logical language, 
as for instance in our example matrix M . 

Constant: A constant A of the logical language of type Z x Z ^ a. 

Definition: The lambda expression representing a double indexed function of 
the form XiXj.f{i, j), where i and j range over the integer intervals [1, m] and 
[1, n], respectively and every f{i,j) is an element of a ring F. In other words 
f{i,j) corresponds to a matrix entry in the column and the row. To 
guarantee that a double indexed function actually constitutes a matrix it has 
to fulfil the property Matrix{f,m,n,F) = \/i € [l,m],j G [l,zz] : f{i,j) G F. 
A concrete example for such a lambda expression is the double indexed 
function representing M above. 

For annotated constants representing concrete matrices the operations for 
summation and multiplication of matrices, scalar multiplication, and transposing 
a matrix are annotated by corresponding procedures. With the tactic simplify 
which applies all possible simplifications specified in annotated procedures, a 
proof step performing the matrix multiplication M 0 M'^ is: 
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Li. {0, 1, 2, 3, 4, 7} e i? (open) 

L 2 . Ring(R,+,-) (open) 

L3. -P=(^ 3117 ^ (open) 

La. -^=(^104)^(^104) (simplify Li, L 2 , L3) 

The line L 3 contains the matrix which is the result of the simplification. 
Since the matrices consist of integers, which are annotated constants again, 
the simplification can compute the result of arithmetic operations on integers. 
The lines Li and L 2 contain the side conditions of the computation. Note 
that the necessary conditions on the size of the matrices Matrix((^l I I)j 2, 3, R) 
and Matrix((l I ,3,2, R) are available from the annotation and thus can be 
checked during the expansion of the tactic simplify. 



4.2 Block Matrices 



A block matrix of the form M = ^ ^ | ^ J can be formally expressed in logic as 

a tuple (/, n + l,n + 1 ,^), in which / is a function from the indices into the 
ring, { 1 , . . . , n + 1 } x { 1 , . . . , n + 1 } ^ F defined as 



XiXj. if i = 1 A j = 1 then a 

elseif i = lA2<j< n+1 then Vj-i 
elseif 2 < i < n+1 A j = 1 then 0 
else cti—ij—i 

If we assume a yf 0 and det(A) yf 0, we can then show that the set of matrices 
of the above form constitute a subgroup of the group of invertible matrices with 
respect to matrix multiplication. This is, however, not straightforward using the 
lambda expression, since a lot of the structural information is needed for the 
argument, which is lost in the lambda term. What we really want to do is to 
lift the argument about 2 x 2 block matrices to a sound argument about general 
matrices. 

In effect the argument can be collapsed into a single computation. By em- 
ulating the block matrix with a 2 x 2 matrix over a non-commutative ring we 
can compute its inverse using the computer algebra system Mathematica [13] 
together with the NCAlgebra package [9] for non-commutative algebra. If we 
replace the block matrix with a matrix of the form 

) , the corresponding inverse matrix is 





Note that can not be further simplified to — since matrix mul- 

tiplication is non-commutative. This computation on concrete matrices can be 
used to determine the inverse of the original block matrix by simply substituting 
for b and A for c: 





326 



M. Pollet et al. 



With the additional fact that a~^ and A~^ exist if and only if a yf 0 and 
det(A) yf 0, the property can be proved. 

Block matrices are implemented as annotated constants in the following way: 

Annotation for Block Matrices: The data structure of 2 x 2 arrays 

where the elements A, B, C, D are either annotated constants for matri- 
ces or double indexed lambda functions. All elements must have the same 
type. In addition, for annotated constants representing matrices the follow- 
ing conditions must hold for the number of rows row{A) = row{B) = r\, 
row{C) = row{D) = T 2 , and col{A) = col{C) = ci, col{B) = col{D) = C 2 
for the number of columns. 

Constant: A constant of type Z x Z ^ a representing the matrix. 

Definition: Block matrices are expanded into a lambda term of the form 




\i\j. 



if 1 < * < ri A 1 < j < Cl 

elseif 1 < i < ri A Ci -I- 1 < j 

elseif ri -I- 1 < t A 1 < j < ci 

else [i.e.,ri -I- 1 < t A Ci -I- 1 < j] 



then A{i,j) 
then B{i,j — ci) 
then C{i - ri,j) 

D{i - ri,j - Cl), 



where the A{.), B{.),C{.), D{.) denote double indexed functions, possibly 
generated by expansion of concrete matrices. 



The annotated constants for block matrices allow us to combine matrices 
given by lambda expressions with concrete matrices. The operations for matrices 
then work directly on the individual blocks of the block matrices. Given double 
indexed functions Uij , Vij , Aij , Bij the tactic simplify applied to the formula in 
Ls results in the following proof situation: 



Li. 

L2. 

Lz- 

U. 

U. 

Le. 



Lr. 



Matrix{uij, 1,2, R) 
Matrix{vij, 1,2, R) 
Matrix{Bij , 2, 2, R) 
Matrix{Aij, 2,2, R) 
{0,1} e R 
Ring{R, -t, •) 



( 1 ) 


^ij © ^ij ) 


0 0 


1 





(open) 

(open) 

(open) 

(open) 

(open) 

(open) 



(open) 



Ls. 





(simplify Li, . . . , L 7 ) 



Line L 7 contains the result of the matrix multiplication and lines Li to Lq 
the side conditions on the objects involved, which cannot be inferred from the 
annotations. 

We describe the simplification stepwise. First the sub-blocks of the matrices 
are multiplied, resulting in 
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/ 

V 



(( 1 ) 0 ( 1 ))© 



oj 0(l)j © 



((1) 0 Uij) 0 (Vij 0 B^j) 



y^ij 0 ^ -^*j) 



\ 



Already at this point the side conditions regarding the double indexed func- 
tions Uij,Vij,Aij,Bij are generated. The requirements for the size can be re- 
constructed from the sizes of the concrete matrices together with the condition 
from the matrix multiplication. Then simplification is applied to the content 
of each sub-block, starting with simplification of the arguments of an opera- 
tion. 

For concrete matrices operations are performed as described in section 4.1. 
For the simplification of operations containing both concrete matrices and double 
indexed functions we only consider the following cases: 

— multiplications involving the zero matrix (i.e., a concrete matrix containing 
only the zero element of the underlying ring) are replaced by the zero matrix; 

— summations with the zero matrix are replaced by the double indexed func- 
tion; 

— multiplication with a concrete diagonal matrix, containing the same element 
on the diagonal is replaced by scalar multiplication with said diagonal ele- 
ment. 

Simplifying the above block matrix with respect to the rules for multiplication 
then yields 




Further simplification employs the rules for addition and also scalar multi- 
plication on 1 • Uij resulting in the formula given in Ty of the above proof. 

The simplification for operations on matrices with mixed representations 
could also be carried out differently, namely by introducing concrete matrices, 
that is 



and then apply simplification on the elements of the matrix. For a = b = 0 
the result will be the same as for our simplification, but in the general case, the 
result is a concrete matrix having elements of the double indexed mixed with the 
elements of the concrete matrix. This means the structure of the initial blocks 
would be lost or hard to recognise. 

While our example works with 3x3 matrices represented as 2 x 2 block ma- 
trices, the argument can be extended to arbitrary nxn matrices still represented 
as 2 X 2 block matrices of the form: 
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But in order to do this we need an adequate treatment of ellipses. 



4.3 Ellipses 

While block matrices already allow us to combine concrete matrices using ar- 
bitrary double indexed functions, they only enable us to combine rectangular 
shapes. Using ellipses we can further generalise the representation of matrices. 
We then need to generalise also the simplifications introduced in the last section 
to matrices with fixed but arbitrary sizes. If we consider our example matrix 



A = 



I' an b 

0 

Vo 



.. 6 \ 

■. b 

0 ajin j 



then A can be represented in higher-order logic as a 4-tuple: (/, n, n, Z) where / 
corresponds to the lambda expression: 



\i\j. if i = j then aij 

if i < j then b 

else 0 



Compared to the concrete instances above, the higher-order representation is 
concise. Nevertheless, in mathematics one develops particular methods for rea- 
soning with matrices of non-concrete sizes, which follow a particular pattern, 
such as triangle matrices, diagonal matrices, and step matrices. Since these pat- 
terns are not necessarily obvious given the lambda term alone it is desirable to 
have the explicit representation of matrices with ellipses available for reasoning. 

Ellipses are realised using annotated constants as well. They are categorised 
into horizontal, vertical, and diagonal ellipses and have the following four at- 
tributes that connect them within the matrix and determine their meaning: 

Begin: A concrete element that marks the start of the ellipsis. 

End: A concrete element that marks the end of the ellipsis. 

Element: The element the ellipses represents; this can either be a concrete 
element such as 0 or 6, or a schematic element such as Ox,?- Here y and ^ 
are schematic variables that indicate that they are iterated over. 

Range: In case the element is concrete (e.g. 0 or &), no range is given. If the 
ellipsis has a schematic term as element, the integer ranges for the necessary 
schematic variables are given. In our example we have 1 < ^ < n and I < 
y < n meaning that both ^ and y take values from 1 to n with increment 1. 



The values for the attributes are determined during parsing of the expression. 
Thereby not all combinations of ellipses are permitted. Essentially, we distinguish 
three basic modules a matrix can consists of: 
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1. points, i.e. single concrete elements. 

2. lines, i.e. an ellipsis or a sequence of ellipses of the same form together with 
concrete elements as start and end points. An example of a line comprised 
of more than one ellipsis is for instance the main diagonal of A where two 
diagonal ellipses constitute a line from an to a„„. 

3. triangles, i.e. a combination of a horizontal, a vertical and a diagonal line. 

Since we only allow for one type of diagonal ellipsis, the we can get exactly 

• ' ' ' • • 

two different types of isosceles right triangles: ’ ■ . : : ’ ■ . 

• • ' ' ' • 



Both start and end elements of an ellipsis are determined by searching for 
a concrete element in the respective direction (i.e., left/right, up/down, etc.) 
while ignoring other ellipses. Both element and range are computed given the 
start and end: If the start and end terms are the same then this term is taken 
to be the element the ellipsis represents and no range needs to be computed. In 
case they are not the same we try to compute a schematic term using unification. 
Although the unification fails it will provide us with a disagreement set on the 
two terms, which can be used to determine the position of possible schematic 
variables. If the disagreement set is sensible, that is, it consists only of terms 
representing integers, the schematic term is constructed and the ranges for the 
schematic variables are computed. 

We illustrate how exactly ranges are computed with the help of some ex- 
amples. Consider the vector (a" • • • aj^), the schematic term is then a| and the 
ranges are ^ G {1, . . . , n} and x G {n, ...,!}. Since these ranges are both over 
the integer and compatible, in the sense that they are of the same length, the 
ellipsis is fully determined. As an example of incompatible ranges consider the 
vector (tti ■ ■ ■ a)j); without further information on n and k the computation of 
the ellipsis will fail. Currently the increment of the range sets is always assumed 
to be 1. The computation of possible index sets is currently more a pragmatic 
one and rather simple. It is definitely not complete since there are many more 
possible uses of indices conceivable in our context. 

An ellipsis is said to be computable if we can determine both begin and end 
element, if the element is either a concrete element or a schematic term, and if 
sensible and compatible integer ranges can be computed. Otherwise parsing of 
an ellipsis will fail. An ellipsis within a matrix gets the same type as the elements 
of that matrix. This means ellipses are generally treated as ordinary terms of the 
matrix, in particular with respect to input, display, and internal representation. 
For instance, our example matrix A is input as the 4x4 matrix 



((a(l,l) b 
(0 ddots 

(vdots ddots 
(0 hdots 



hdots b ) 

ddots vdots ) 
ddots b ) 

0 a(n,n))) 



and is also represented internally as a 4 x 4 array. However, the simplifications 
can use the information provided by the ellipsis during the reasoning process. 
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When a matrix containing ellipses is expanded into a lambda term the expan- 
sion algorithm translates the ellipses into appropriate conditions for the if-then- 
else statements. Thereby the matrix is first scanned and broken down into its 
components, i.e. points, lines, and triangles. These can then be associated with 
corresponding index sets and translated into a lambda expression. For instance 
the diagonal ellipsis in our example matrix A above can be simply translated 
into the conditional if i = j then a^, while the areas above and below the main 
diagonal where a horizontal, a vertical, and a diagonal ellipsis bound the area in 
which all the elements are either 0 or b. In an additional optimisation step neigh- 
bouring triangles are compared and can be combined to form rectangular areas. 

The simplification for operations on matrices are extended to the cases where 
matrices contain ellipses. For example, the sum of matrices where both matrices 
contain ellipses at the same positions results in a matrix containing the sum of 
concrete elements and the ellipses between those elements. The multiplication 
of a diagonal matrix containing the same element on the diagonal is reduced to 
scalar multiplication with this element. 

5 Conclusions 

Formal representations of mathematical objects often do not model all impor- 
tant aspects of that object. Especially some of the structural properties may 
be lost or hard to recognise and reconstruct. In our work we investigated these 
structural properties for the case of matrices where there exist different rep- 
resentations for different purposes. Each representation has certain reasoning 
techniques attributed to it. 

We modelled the structural knowledge about concepts with the help of anno- 
tations, which are used to identify objects and to store information about them. 
We implemented the different representations for matrices as annotated con- 
stants and showed how basic simplifications are performed. The representations 
for block matrices and ellipses allow us to represent matrices of a general form. 
Annotations are also used for manipulations of objects. Instead of deduction on 
formulas, many manipulations can be reduced to computations on annotations. 
Since we are able to express general matrices, we can express general properties 
and theorems based on our formalism. With simplifications performed on gen- 
eralised matrices we are now able to express complex reasoning in the form of 
computational steps. In future work we want to investigate how this can further 
aid in the construction of actual proofs. Remember that we currently deal an- 
notated constants, that is, only with ground terms. Thus, it would be useful to 
extend the work in a way that allows also to deal with variables. 

Annotations preserve the correctness by their implementation as constants of 
the formal language. The proof construction is split into a phase where steps are 
performed based on the richer knowledge contained in annotations and a verifi- 
cation phase where these steps are expanded to calculus level proofs. The expan- 
sion is currently only implemented for a subset of the operations. The expansion 
mechanism for proof steps using annotations needs to be simplified and gener- 
alised. The use of canonical forms should help keeping this expansion simple. 
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Our work compares to de Bruijn’s idea of a mathematical vernacular [3], 
which should allow to write everything mathematicians do in informal reason- 
ing, in a computer assisted system as well. In this tradition, Elbers looked in [4] 
at aspects of connecting informal and formal reasoning, in particular the in- 
tegration of computations into formal proofs. Kamareddine and Nederpelt [5] 
have formalised de Bruijn’s idea further. While the approach to a mathematical 
vernacular is general, to our knowledge no attempt has been made to incorpo- 
rate concrete objects like matrices directly. In the Theorema system Kutsia [7] 
has worked with sequence variables which stand for symbols of flexible arity. 
Sequence variables have some similarities to our ellipses. However, as opposed 
to sequence variables our ellipses allow only fixed interpretations. Moreover se- 
quence variables can be viewed as an extension of the logical system which 
allows to deal with these expressions within the logic. The main emphasis of our 
work is to allow for representation within logic and extra-logical manipulation 
of expressions at the same time. Bundy and Richardson [2] introduced a general 
treatment for reasoning about lists with ellipses in a way that they consider an 
ellipsis as a schema which stands for infinitely many expressions and a proof 
about ellipses stands for infinitely many proofs, which can be generated from a 
meta-argument . 
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Abstract. In this paper we analyse the modifications on logical oper- 
ations - as proof checking, type inference, reduction and convertibility 
- that are required for the identification of a proof assistant environ- 
ment with a distributed mathematical library, focusing on proof assis- 
tants based on the Curry-Howard isomorphism. 

This identification is aimed at the integration of Mathematical Knowl- 
edge Management tools with interactive theorem provers: once the dis- 
tinction between the proof assistant environment and a mathematical 
library is blurred, it is possible to exploit Mathematical Knowledge Man- 
agement rendering, indexing and searching services inside an interactive 
theorem prover, a first step towards effective loosely-coupled collabora- 
tive mathematical environments. 



1 Introduction 

The main goal of Mathematical Knowledge Management (MKM) is the creation 
of large distributed libraries of mathematical knowledge and the development 
of tools to manage, render, data mine, index and retrieve the notions in these 
libraries. Mathematical Knowledge Management does not study the process of 
new mathematical knowledge creation by a mathematician, but is expected to 
have a substantial impact on it: the better the existent knowledge is grasped and 
retrieved, the quicker the process of creation. For instance, recent studies [2, 3] 
implement an authomatic knowledge discovery framework by tightly integrating 
Mathematical Knowledge Management with authomatic theorem proving: the 
existent mathematical knowledge is used to derive new definitions, to guess in- 
teresting properties and to drive the theorem prover by suggesting well known 
proof techniques; the theorem prover is used to detect the properties that hold 
and prune out wrong guesses. 

It is not known whether all the expectations will be met or whether the 
mathematicians will not adopt the Mathematical Knowledge Management tools 
finding them useless. Nevertheless, we already have evidence of the necessity for 
them in the restricted domain of interactive theorem proving. The mathemati- 
cian that deals with formal mathematics has to develop her own theories on top 
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of large bases of apparently trivial facts that nevertheless need to be proved and 
retrieved. Mathematical Knowledge Management techniques are necessary since 
large knowledge bases can be developed only collaboratively and since often the 
facts in them are so obvious event not to have a name easy to remember, so to 
be effectively retrieved only using the advanced indexing techniques developed 
in MKM. 

Proof assistants - also called interactive theorem provers - are based on the 
notion of environment, that is the knowledge base that is local to one develop- 
ment and that is interactively augmented. Logical operation (as proof-checking) 
and extra-logical utilities (as rendering and searching) operate on the proof as- 
sistant environment only. 

To achieve full integration with Mathematical Knowledge Management tools, 
the natural path is blurring the distinction between a distributed mathematical 
library and the environment of a proof assistant, consequently replacing every 
extra-logical utility that is limited to the environment only with the correspond- 
ing Mathematical Knowledge Management tool that operates over the whole 
distributed library. 

In this paper we analyse the necessary modifications on the logical operations 
for the identification of the proof assistant environment with a distributed math- 
ematical library, focusing on the proof assistants based on the Curry-Howard 
isomorphism. 

In Sect. 2 we present the Calculus of Constructions as a paradigmatic example 
of the logic of a proof assistant based on the Curry-Howard isomorphism. In 
particular, we detail the classical presentation of the reduction and typing rules 
of the calculus, and we analyse the role of the environment in this presentation. 

Since the rules are not syntax oriented, implementations are based on an 
alternative version that also handles the environment in a completely different 
way. This operational presentation of the rules is described in Sect. 3. Both set 
of rules are not well suited for the replacement of environments with distributed 
mathematical libraries. 

In Sect. 4 we present a third original version of the rules that differs from the 
operational presentation in the way environments are constructed: instead of the 
operational “bottom up” construction of the environment, based on well-typed 
extensions of the current environment, we present a “top down” approach where 
the environment is considered to be a subset of the mathematical library and 
where the environment necessary to type-check a definition can be dynamically 
inferred during type-checking. 

Intuitively, in the classical approach the environment is a consistent space 
of mathematical notions, that can only be augmented if its consistency is pre- 
served. No notion outside this consistent space is accessible and no operation 
can be performed on it. In our approach, instead, there is a much larger space of 
connected and maybe conflicting mathematical notions, that is the mathemati- 
cal library. We can associate to every point in the space an environment that is 
the minimal consistent subspace that contains the point and that is closed for 
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references (i.e. occurrences of lemmas and definitions). It is possible to operate 
on the whole space as long as inconsistent subspaces are not considered at once. 

Section 4 analyses the practical relevance of the contribution presented in 
this paper, whereas Sect. 5 describes future work. 



2 The Calculus of Constructions 

In this section we present a variant of the Calculus of Constructions (CoC) [5] as 
a paradigmatic example of a calculus used to implement proof assistants based on 
the Curry-Howard isomorphism. The given presentation is obtained by removing 
from the Calculus of (Co)Inductive Constructions - the calculus of the Coq 
proof assistants^ ~ all the rules that deal with local definitions and (co)inductive 
types. The part of the calculus that deals with universes is preserved, but is 
simplified (hence making it less expressive). The motivation is the complexity 
of the omitted rules, that are largely orthogonal to the topic addressed in this 
paper. Nevertheless, in the author’s PhD. dissertation [9] the whole Calculus of 
(Co) Inductive Constructions is considered. 

Since CoC is (an extension of) a Pure Type System, we could adopt Pure 
Type Systems extended with constants as our paradigmatic example. Neverthe- 
less, the generalization of what we propose to Pure Type Systems is a trivial 
exercise and casts no additional light on the topic. Moreover, our formalization 
has the additional benefit of being closer to the calculus actually implemented 
in the proof assistant Coq. 

2.1 Syntax 

Let V be a denumerable family of variable names, x,y, z, . . . G V. 

Let C be a denumerable family of constant names, c, ci, . . . , c„ G C. 

Well formed terms (represented by t,f,u,T,U,N,M) are inductively defined 
as follows. 

t ::= X identifiers 

I c constants 

I Set I Prop I Type(j) sorts 

I (t t) application 

I Aa; : t.t A-abstraction 

I Ux : t.t dependent product 

Identifiers are references to locally bound variables, whereas constants are 
references to global definitions that are collected in an ordered list called an 
environment. The terms Set, Prop and Type(i) are called sorts and are indexed 
by s. Sorts are the types of a type. In particular, the sorts Prop and Set are 
used to type respectively propositions and data types. Every sort is typed by 
another sort Type{i) characterized by a greater index i (the index of Prop and 
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Set is 0). A A-abstraction Ax : t\.t 2 is a function whose input x is of type t\ and 
whose output is the expression t 2 - A dependent product ilx : ti.t 2 is the type 
of all the functions whose input x is of type ti and whose output is of type t 2 - 
The variable x is bound in t 2 both in A-abstractions and dependent products. 
Free variables, substitution and a-conversion are defined as usual. Terms are 
syntactically identified up to a-conversion. 

2.2 Environments and Contexts 

As environments are ordered lists used to collect global definitions, contexts are 
ordered lists used to collect local declarations. Contexts and environments are 
formally defined by the following grammar: 



r ::= [] 


empty context 


1 T.(x:T) 


declaration of x of type T 


E ::= [] 


empty environment 


1 E.{c:T-.= t) 


definition of c as t of type T 



We assume that no variable x is declared twice in a context and that no 
constant c is declared twice in an environment. The typing rules of the calculus 
enforce this invariant. 

We write (x : T) € T if x is declared in F to have type T. Similarly, we write 
(c : T :=t) € E if cis defined in E to be t of type T. 

2.3 Reductions and Convertibility 

The syntax of the CoC allows to define and apply functions. The reduction rules 
of the calculus describe how the result of a function application is computed. 
We define two reduction rules: ^-reduction and /3-reduction. 

^-reduction states that a constant occurrence can be replaced with its definien- 
dum: 

c>st if {c : T := t) G E 

/3-reduction substitutes the application of a function to its argument with the 
body of the function, replacing the formal parameter with the actual argument: 

(Ax : T.M N) >0 M{N/x} 

Additionally, the substitution operator M{N/x} takes care of avoiding cap- 
turing of free variables of N. 

The reflexive, symmetric, transitive and context-aware closure = 0 s of ^- 
reduction and /3-reduction is called convertibility. The reduction rules form a 
strongly normalizable rewriting system [11]. As a consequence, convertibility is 
a decidable property: to decide whether two terms are convertible we can test 
a-convertibility of their normal forms. More efficient algorithms based on weak 
head reduction are used in real world implementations [8,9]. 

Since convertibility is a decidable equivalence relation, it is practical to iden- 
tify terms up to convertibility. Concretely, this means reducing the number of 
human provided deduction steps of a proof by replacing them with machine 
performed computational steps. 




336 



C. Sacerdoti Coen 



2.4 Typing Rules 

We give the typing rules of CIC by mutually defining two judgements. The first 
one, E\r] \- t T, asserts that t, in an environment E and a context E that 
depends on E, has type T. The second one, WE{E)[r], asserts that if is a valid 
environment - i.e. it is acyclic and it comprises only well-typed definitions - 
and that T is a valid context in if - i.e. it is acyclic and it comprises only well- 
typed variable declarations. An environment E is acyclic when each constant 
definition d may refer only constants defined before d in E. Similarly, a context 
T in if is acyclic when each variable declaration d may refer only constants 
in the environment E or variables declared before d in T. Cyclic environments 
and contexts must be avoided since in general they correspond to non well- 
founded (and logically inconsistent) recursive definitions. Finally, we will see 
that E[r] \- t : T implies WE{E)[E] for each couple of terms t and T. 

The rules of the two judgements are given in Table 1. The Conv rule is the one 
responsible for the identification of convertible terms. The version proposed here 
is a major simplification of the corresponding rule adopted in the Coq system 
and adapted from ECC [7]. In the original rule the equivalence relation =i 3 s is 
replaced by an order relation < 0 s that admits cumulativity between universes. 
Cumulativity grants that each term of type Type(z) is also of type Type(j) 
for each j > i (and is expressed by the rule Type(z) <iss Type(j). The order 
relation can also be extended to relate non-convertible function spaces (and 
sigma types, if available) when their input types (in contra-variant position) are 
convertible and their output types (in co- variant position) are in <iss- The choice 
of the less expressive version of the rule avoids further complications that are 
orthogonal to our proposal. 

This version of the typing rules is the one usually presented in theoretical 
dissertations about the Calculus of Constructions, since it is the presentation 
that more easily allows to prove metatheoretical results. Notice, however, that 
this formulation is not syntax directed: to type-check a term t it is always possible 
to apply both the Conv rule and the rule - or the rules when t is a dependent 
product - that match the syntactic structure of the term. Thus implementations 
are usually based on an alternative syntax directed presentation of the typing 
rules of the calculus. 

In Sect. 3 we will present the syntax directed version of the typing rules of 
the calculus. Before that, let’s analyze the way the environment is handled in 
the typing rules already given. 



2.5 Environment Handling 

First of all, by inspection of the typing rules of the E[F] \- t : T judgement we 
notice that the environment E is never modified (i.e. the same environment is 
used both in the conclusion and in every hypothesis). Moreover, every internal 
node of the derivation tree but conversion nodes (rules Prod-SP-Conv) does not 
directly exploit the environment. The conversion rule access the environment to 
compute ^reduction steps, but without checking its validity. On the contrary. 
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Table 1. Typing rules, original formulation 



WF-Empty 

WF-Var 



WF-Const 



[])[[]] 

E[r] \- T : s s € {Prop, Set,Type(i)} x ^ F 
WF{E){r, {x : T)] 



-E[[]]l-r:s s £ {Prop, Set, Type(i)} E[[]] t : T c^E 





WT{E-c-.T 


Ax- Prop 


WE{E)[r] 

E\r] h Prop : Type(n) 


Ax-Set 


WE{E)[r] 

E[E] h Set ; Type(n) 


Ax-Acc 


WE{E)[r] n<m 




E[T] h Type(n) : Type(m) 


Var 


WE{E)[r] {x:T)£T 

E[F] h a; ; T 


Const 


WE{E)[r] {c:T-.= t)£E 




E[F] \-c:T 


Prod-SP 





E[r] T : Si E[E, {x : T)] U : S2 si € {Prop, Set} or S 2 G {Prop, Set} 

E[F] h Ex : T.U : 82 



Prod-T 



E[r] h T : Type(ni) E[E, {x : T)] h U : Type(n2) m < n ri2 < n 
E[r] h IIx : T.U : Type(n) 

Lam 

E[F, {x:T)]\-t-.U E[F] \- Ex : T.U : s 
E[F] h Ax : T.t : Ex : T.U 

App 

E[T] ^t-.Ex-.U.T E[F] !-«:[/ 

E[E] h (t m) : T{u/x} 

Conv 

E[F] h Ti : s E[F] h t : T2 E[F] h Ti =ps T2 
E[F] \-t-.Ti 



all the leaves of a derivation tree (rules Ax-Prop-Const) check the validity of 
the environment by testing WE{E)[r]. Due to our previous observation, this 
means that a proof of WT{E)[r] for the same version of E and E is required 
at each leaf of the derivation tree. Of course, this is totally unreasonable from 
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an implementation point of view. Thus the operational presentation of the rules 
will take care of this, granting that a couple (E,r) will be checked only once. 

Let’s focus now on the derivation rules of the WT{E)\r] judgement. The 
applications of this rules are stratified: first of all the WF-Var rule is applied 
several times to remove one after the other all the declarations in the context F ; 
then the WF-Const rule is applied several times to remove one after the other 
all the definitions in the environment E. Finally a single application of the WF- 
Empty rule ends the proof. In the first phase - the applications of the WF-Var 
rule - the environment E is also never modified. 

From the previous observations we conclude that the only rule that destruc- 
tures the environment E is the WF-Const rule. The WF-Const rule checks for 
well-formedness of the environment E' obtained removing from E its last el- 
ement; then it checks for the well-typedness of the definition in the environ- 
ment E' . By induction on the height of the derivations we can easily prove that 
eventually every element of E is checked for well-formedness in a derivation of 
WT{E)\\. Interestingly, however, this check is apparently done “on demand”: the 
well-formedness of the environment E is not checked before starting the proof 
of E[r] \- t : T, but only during its proof, whenever an occurrence of a constant 
is met. However, every constant in E is checked, even if it does not occur in 
r, t and T. In the latter case, the thinning lemma [11] states the uselessness of 
the check, since unused constants can be removed from the environment with- 
out affecting well typedness. This suggests that checking “on demand” can be 
improved to avoid unused definitions. 

The previous observations imply that the standard presentation of the type- 
checking rules is not appropriate for a direct implementation, especially if the 
environment is substituted by a large and distributed mathematical library, since 

— the parts of the library that are not useful to type-check the term under 
consideration are checked anyway; 

— each object in the library is checked more than once. 

In the next section we analyse the standard operational presentation of the 
type-checking rules, discussing how the environment is handled. 



3 Syntax Directed Type Checking Rules 

The syntax directed (or operational) version of the reduction and type-checking 
rules of CoC solves at once two problems of the previous presentation: each 
definition in the environment is checked at most once; and at most one type- 
checking or reduction rule can be applied to a given term (respectively to a 
couple of terms). 

Thanks to the latter remarkable property the operational presentation of the 
rules yields an efficient algorithm that does not require backtracking. However, 
in this paper we are more interested in the first property. 

The key idea that underlies the management of the environment is the fol- 
lowing already noticed invariant: the environment is consulted, but it is never 
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modified during the type-checking of a term t in the context F. Thus it is pos- 
sible to define the (current) environment as an abstract data type with two 
methods: the first one returns the definition of a constant c in the environment; 
the second one appends a definition to the environment. The latter method 
checks for the well-typedness of the definition before appending it. The initial 
environment is the empty environment (that is always well- formed) . The invari- 
ant that is granted by the two method implementations is the well-formedness 
of the environment. Thus, in the following typing rules, we can always assume 
the environment E to be well-typed. 

The expression whd{E,t) that occurs in the typing rules compute the weak 
head normal form of t in the environment E. The judgement E[E] h < J, t' is 
a syntax directed formulation of the convertibility judgement. It satisfies the 
property E[F] \- t I t' iS E[F] h t =/ 3 s t' . A set of rules for the E[E] \~ t [ t' 
judgement that yield and efficient implementation can be found in [8,9]. 

The rules of the typing judgement are given in Table 2. The premise (c : T := 
t) & E oi the BU-Const rule is implemented by calling the first method of the 
abstract data type that implements E on the constant name c. The definition 
{c : T := t) is the result of the method invocation. 



Table 2. Typing rules, operational formulation 



BU-Ax-Prop 



BU-Ax-Set 



E[r\ h Prop : Type(i) 



BU-Ax-Acc 

BU-Var 

BU-Const 

BU-Prod 

BU-Lam 

BU-App 



E[F] h Set : Type(i) 
n < m 

E[E] h Type(n) : Type(m) 

{x-.T)ar 
E[E] h a; : T 

{c:T :=t) eE 
E[r] c:T 

E[E] \-T-.Si whd{E[r], Si) = Si 

E[r, {x:T)]\-U : S 2 whd{E[r, {x : T)], S 2 ) = S 2 
E[E] h nx : T.U : sj 

E[E] \-T :S whd{E[r], S) = s E[E, {x : T)] \- t : U 
E[E] h Ax : T.t : Hx : T.U 



E[E] \-t:S whd{E[r], S) = nx: U.T E[E] \- u : U' E[E] \~ U I U' 
E[E] (tu): T{u/x} 
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To grant the well-formedness of the environment, a definition {c : T := t) is 
appended by the second method only if the following conditions are satisfied: 

c^E E[[]]hT:S whd{E[[],T) = s E[[]]ht:T' S[[]] h T' i T (*) 

As already stated in the introduction of the paper, the major drawback of this 
management of the environment is that the environment must be constructed in 
a “bottom up” fashion, checking in advance all the results that will be needed 
for the mathematical result the user wants to develop. Since it is common to 
discover the need for a lemma during the development of a proof, the bottom 
up environment construction can be an annoying limitation. 

For instance, let us consider the following scenario: the user knows (or finds 
using a search engine) that there is a lemma in the mathematical library that 
she would like to use. The lemma is not part of the current environment and 
it depends on other lemmas and definitions that are not part of the current 
environment. Thus she is obliged to add to the environment all these lemmas 
and definition in the right order, i.e. without appending a definition that relies 
on another definition not appended yet. If she is able to append all the lemmas 
and definitions, comprising the wanted lemma, then the obtained environment 
is well-formed and she can apply the lemma. 

Since we cannot expect the user to perform by hand the previous mechanical 
operations, we can delegate them to an external software agent. However, this 
solution is not efficient, since all the terms of all the definitions that must be 
added to the environment are browsed twice: the first time to collect all their de- 
pendencies to compute their topological sorting; the second time to type-check 
them. Moreover, bugs in the topological sorting algorithm are difficult to de- 
tect since they manifest themselves by producing non well-formed environments 
whereas well-formed environments can be produced. 

Finally, notice that the syntax directed type-checking judgement is not a 
complete formal description of the type-checker, since the data type and its 
implementation must also be described, as well as the additional constraints (*). 

In the following section we propose yet an alternative formulation of the type- 
checking judgement. The formulation proposed is syntax oriented, yielding an 
algorithm that can be mechanically implemented. The environment is managed 
in a “top down” fashion, being constructed (identified) only on demand, in a 
“call- by-need” fashion. Concretely, an environment is a consistent subset of a 
larger (and possibly inconsistent) mathematical library. Thus the user is always 
free to use at any time a lemma in the library that is not yet in the environment. 
Finally the judgement proposed is self-contained, no longer requiring an external 
data type. 



4 Mathematical Libraries as Environments 

Let £ be a (possibly inconsistent) mathematical library (i.e. a set of constant 
definitions (c : T := t)). An environment if is a consistent subset of C. We define 
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two mutual judgements, {^)E[r\ \- t :T K E' and fetch{<l>, E, c, E' , {c: T := t)), 
with the following semantics: 

— fetch{<P, E,c, E' , {c : T := t)) holds when the environment E C L, assumed 
to be consistent, can be extended to a new consistent environment E' Q C 
such that i? is a prefix of E' , no constant in the set of constant names is 
defined in E' and {c : T := t) G E' where {c : T := t) G C. 

Concretely, the judgement defines a function whose input is the triple 
(^, E, c) and whose output is the couple {E' , c:T :=t). We say that E' is the 
(minimal) context extension of E that includes c. The set of constant names 
^ is a technical trick used to detect cycles in the constructed environment 
extension. 

— {E)E\r] h t : T t<i if' holds when t has type T in the environment E' and in 
the context E and E' is an extension of E (assumed to be consistent) such 
that all the constants in the set of constant names <P are not defined in E' . 

Concretely, the judgement defines a function whose input is the tuple 
E, r, t, T) and whose output is the minimal environment extension E' in 
which the input is we 11- typed. 

The rules of the two judgements are given in Table 3. The following two 
theorems, whose proof can be found in the author’s PhD. dissertation [9], state 
the equivalence of the proposed judgement with the standard presentation. 

Theorem 1 (Soundness). For each environment E, context F , list of refer- 
ences <P and term t such that the intersection between the domain of E and <P is 
empty, ifWF{E)[r] and {F)E[r] h t : T ixi if' then 

— WT{E')[F] 

— the intersection between the domain of E' and is empty 

— for each couple of terms t' , T' such that E[F] h t' : T' we also have E'[F] h 
t' : T' 

— E'[F] Gt:T. 

Theorem 2 (Completeness). For each environment E, context F and term 
t, if'WF{E)[F] and E[F] \- t \T, then there exists an unique term T' such that 
{d})E[F] Gt-.T' t<E and E[F] h T =fss T' . 



Practical Relevance 

The main aim of this paper is the development of a type-checker that blurs as 
much as possible the distinction between the logical environment and the math- 
ematical library, giving to the user the feeling of building her own development 
on top of the whole library. All the mathematical results in the library must 
seem to be always available, even if they have not been type-checked and put in 
the environment so far. 

The typing judgement proposed satisfies at once several properties that al- 
together yield almost mechanically the implementation of a type-checker that 
satisfies our needs. Indeed 
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Table 3. Typing rules, proposed new operational formulation 



TD-Ax-Prop 

{<P)E[r] h Prop : Type M E 

TD-Ax-Set 

(<?)B[r] h Set : Type M E 

TD-Ax-Acc 

{•E)E[r\ Type : Type [xl E 

TD-Var 

(x ■. T) & r or {x : T := t) & r 
i<l>)Elr] h r : T M £ 

TD-Const 

fetch('P, E, c,E',{c-.T ■.= t)) (<f)E'[r] 

{<P)E[r] h c-.Tc^E' 

TD-Prod 

(<f)£;[T] h T : Si x B' ■!«?id(B'[r], Si) = si 

{<P)E'lr, (£C : T)] h (7 : S 2 IXI E" whd{E"[r, (x : T)], S 2 ) = S 2 
(<?)B[r] h Ex : T.U : S 2 ixl E" 

TD-Lam 

(<f)B[r] h T : S IXI B' whd(E'[r],S) = s (<f)B'[B, (r : T)] h t : B ixi B" 

(<P)B[B] h Xx : T.t : Ex : T.U ixl B" 

TD-App 

(<f)B[B] h t : S IXI B' i«?id(B'[r], S) = 77a; : C/.T (<f)B'[7"] h « : B' M B" B"[B] h B i B' 

(<7i)B[r] h (t «) : T{«/a;} M B" 



TD-fetch-Const-hit 



TD-fetch-Const-miss 



(c : T := t) G B 
fetch{d>^ B, c, E, {c : T := t)) 



c ^ <P {c : T ■.= t) G C 

(<7i;c)B[[]] h T : S IXI B' whd{E'H]],T) = s 

(<?; c)B'[[]] h t : T' CXI B" B"[[]] h T' ) T 

fetch(-I>, E, c, B"; (c ■. T ■.= t) , (c ■. T ■.= t)) 



— the type-checking rules are syntax oriented; 

— every object in the environment is checked only once; 

— every object in the library is checked at most once, and only if necessary; 

— the environment necessary to type-check a term is reconstructed on-the-fly 
during type-checking; 

— the typing judgement is self-contained and fully describes the type-checker 
kernel. 

Soundness (theorem 1) grants two useful implementation properties. The 
first one is what we name minimal environment reconstruction: given a term t, 
if ( 0 ) 0 [[]] t : T (xi E, then E is the smallest well-formed environment required 
to type-check t. 

We call the second property environment extension: in order to check a new 
term, definition or declaration for well-formedness, we do not have to throw away 




Mathematical Libraries as Proof Assistant Environments 



343 



the already computed and well- formed environment. We can simply invoke the 
type-checking procedure passing the current environment as the initial environ- 
ment. In case of success, the returned environment is the minimal extension of 
the initial environment that grants the well-formedness property. 

Environment reconstruction paves the way to the notion of trusted informa- 
tion source. A trusted information source is a subset of the distributed library 
of knowledge that is closed (in the sense that it is well-formed) and that we 
can trust to be also consistent. Concretely, trusting an information source C' 
amounts to adding a new inference rule that deals with the fetch relation, and 
to slightly change the reduction rule that deals with 6 reduction: 
0-fetch-Const-trust 



{c-.T:=t)e C 

fetch{d>, E, V, E;{c:T := t) , {c : T := t)) 



The rule for ^-reduction is changed by replacing the premise (c : T := t) € E 
with the premise {c : T := t) G E or {c : T := t) G C . 

Basically, the new rule above means that a declaration or definition in a 
trusted information source C can always be considered as well-formed. Equiv- 
alently, it says that C can always be considered as a subset of any well-formed 
environment. 

The proposed typing judgement, extended with trusted information sources, 
has been implemented in a proof-assistant kernel prototype developed in project 
HELM^ (Hypertexual Electronic Library of Mathematics) [1] and it has already 
been in use for a couple of years. The prototype consults the HELM mathemat- 
ical library of about 40000 lemmas and definitions extracted from the Coq proof 
assistant [10]. The library is physically distributed among several repositories. 
One of the repositories provides the standard library of the Coq proof assistant, 
that is granted to be closed and consistent. Thus the repository is considered a 
trusted information source, whereas all the other repositories are untrusted. 

Recently, the kernel of the proof-assistant prototype has been embedded in a 
fully fledged tactic-based interactive theorem prover, that implements also refine- 
ment and unification. Unification is an extension of convertibility that handles 
missing or incomplete information: two open terms can be unified if there exists 
a substitution that makes them convertible. In a similar way refinement is an 
extension of convertibility that handles missing or incomplete information: an 
open term is refinable when there exists a substitution that makes it well-typed. 

In the author’s PhD. dissertation [9] the technique presented in this paper is 
extended to cover also unification and refinement. Thus the user of the HELM 
proof-assistant is never exposed to the notion of environment: all she knows 
about is the mathematical library that she can search, render and data mine and 
that she can freely extend, as long as no inconsistency is added. The searching, 
rendering and data-mining components of the prototype are off-the-shelf MKM 
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services developed in project HELM and in project MoWGLI^ (Math on the 
Web: Get it by Logics and Interfaces). 



5 Future Work 

The Galculus of Gonstructions and its extensions - as the Galculus of (Go)Induc- 
tive Gonstructions adopted by Goq ~ is formalized by imposing a linear ordering 
over the sorts Type: Type(i) < Type(j) whenever i < j. The ordering is just 
used to avoid circularities, that may correspond to logical inconsistencies. No 
assumption is made in the meta-theory of the calculus about its linearity. 

However, implementations of the Galculus of Gonstructions are usually based 
on a different sorts representation, where the order relation is a partial order that 
is automatically inferred by the system and that can be represented as an acyclic 
graph. The benefits of this solution are twofold: on the one hand the user is given 
the illusion to work in a simpler (but inconsistent, [4]) impredicative system that 
has only one sort Type : Type; on the other hand the system is more flexible 
in the definition of new sorts and new constraints about the sorts. 

For instance, in the classical presentation it is not possible to add a new sort 
Type(z) between Type(l) and Type(2) unless every sort Type(j) such that 
j > 2 is shifted. Even worse, given two logically unrelated sorts Type(n) and 
Type(m) we are obliged to artificially fix an order ~ say n < m - unless we are 
using a partial order. Once the order n < m is fixed, the usage of a lemma that 
generates the logical constraint m < n is rejected even if the detected cycle does 
not correspond to a real logical inconsistency. 

As a future work, we are planning to detail and implement a version of the 
typing judgement that is based on a partial order implemented as an acyclic 
graph. Since constraints (arcs) among the sorts are introduced during type- 
checking, we must extend our judgement to build the sorts graph on-demand 
during environment reconstruction and extension. 

One interesting property of this approach with respect to the usual imple- 
mentation is that the sorts graph inferred by the environment reconstruction 
procedure is minimal, in the sense that no constraint can be relaxed without 
losing the well-typedness of the declaration. 

Unfortunately, in case of failure during an environment extension we are not 
allowed to conclude that the given term, declaration or definition is not well- 
typed. For instance, it may be the case that no well-formed extension of the 
current environment grants well-formedness, simply because of a conflicting set 
of constraints. Nevertheless, it may be the case that some of the conflicting con- 
straints are derived from parts of the initial environment that are not necessary 
to type-check the given input [6]. Thus, to conclude that the input is not well- 
formed, we are obliged to repeat the check starting from the empty environment. 

Notice that the problem we have just noticed is not a side-effect of our special 
handling of the environment. Indeed, our approach is the only one that allows 
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to overcome the problem, by reconstructing the minimal necessary environment. 
In the Coq system, for instance, when such a case is met the only solution is to 
factorize out of the required modules^ all the definitions necessary to type the 
incriminated definition. Basically this amounts to perform by hand the operation 
of environment reconstruction. 

It should be noted, however, that the cases where the problem arises are very 
uncommon. All the cases known by the author are to be found in the encoding of 
set theories and the theory of categories where big and small sets (or categories) 
are mixed together in the same development. Nevertheless, once again we feel 
that, in the context of mathematical knowledge management, the problem must 
be faced in a serious way, since it can deeply hinder the possibility of extending 
or reusing a development in the long term. 

To integrate the inference of the sorts graph 7 in the environment reconstruc- 
tion procedure, all the rules need to be given the sorts graphs an additional input 
and output. Moreover, the fetch relation becomes also responsible for extending 
the system of constraints by adding the constraints that are required to type- 
check the reference object. Thus, in order to obtain a sound implementation, we 
need to keep, for any object in a trusted information source, the minimal set of 
constraints imposed during its type-checking. Let K. be the map that associates 
the constraints to a reference r. The fetching rule is changed in the following 
way: 

TD-fetch-Const-trust 

{c:T:=t)€C WT{-fUlC{c)) 

fetch{<P, {E,j),c, {E; (c : T := t), 7 U /C(c)), (c(ui, . . . ,u„) : T := t)) 

where 7 is the set of constraints in input, U is the operation that merges two set 
of constraints and 7') is the new judgement that checks if the merge of 

two set of satisfiable constraints is satisfiable (i.e. it does not contain any cycles). 
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Abstract. Mathematical notation has the characteristic of being am- 
biguous: operators can be overloaded and information that can be de- 
duced is often omitted. Mathematicians are used to this ambiguity and 
can easily disambiguate a formula making use of the context and of their 
ability to find the right interpretation. 

Software applications that have to deal with formulae usually avoid 
these issues by fixing an unambiguous input notation. This solution is 
annoying for mathematicians because of the resulting tricky syntaxes 
and becomes a show stopper to the simultaneous adoption of tools char- 
acterized by different input languages. 

In this paper we present an efficient algorithm suitable for ambiguous 
parsing of mathematical formulae. The only requirement of the algorithm 
is the existence of a “validity” predicate over abstract syntax trees of 
incomplete formulae with placeholders. This requirement can be easily 
fulfilled in the applicative area of interactive proof assistants, and in 
several other areas of Mathematical Knowledge Management. 



1 Introduction 

Mathematicians are used to well established and ambiguous notational conven- 
tions. To design a software application which have to deal with mathematical 
formulae, we have to consider this habit. 

Sometimes a mathematician who is reading a formula, solves the ambiguity 
using the notion of context: for instance, if / is known to be a scalar value, then 
f~^ is the inverse value 1//; if / is a function, then f~^ is probably the inverse 
function of /. 

More often the context is not sufficient and the ambiguity is solved by picking 
the only interpretation that makes sense or the interpretation that is more likely 
to have one. For instance, without additional information, a mathematician is 
like to interpret as (0o </))(x) although sin^(a;) is probably interpreted as 

(sina;)^. 

Associating precedences to operators does not always solve ambiguity prob- 
lems as shown by the combined usage of conjuction and equality operators: 
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A A B = B A A is usually interpreted as equality of conjuctions whereas 
x = yAy = x as conjuction of equalities. 

Using unambiguous grammars computer scientists avoid ambiguity problems 
in programming languages and programmers are used to learn them from scratch 
along with their ad hoc syntactical rules. Mathematicians can of course do the 
same with new proof assistants or other Mathematical Knowledge Management 
(MKM) applications. Notwhithstanding this fact, there are motivations for try- 
ing to recognize ambiguous mathematical inputs in the MKM context. In the 
following paragraphs we try to identify some of them. 

Different mathematicians adopt for the same concept different notations. We 
do not want to give up this possibility for technical reasons. In MKM indeed 
there are several situations where the user has to write or read a mathematical 
formula without knowing the context, in which notations are defined. Let us 
consider a search engine for mathematical results, as the one described in [5]. 
The user enters a statement to retrieve all its proofs. In order to do so, she has 
to pick a notation and use symbols and constants that are not fixed by any 
context. Thus the search engine has to be able to parse the ambiguous sentence, 
disambiguate it and perform the search modulo the context. 

A feature that is usually provided to the user of a Computer Algebra System 
(CAS) or a proof assistant is that of defining new notations, which are stored in 
the context. Sooner or later it will happen that a user needs to merge together 
two contexts where the same notation is used for different concepts. If these 
systems do not handle overloading, the easiest form of ambiguity, at least one of 
the two notations is actually masked and the user has to redefine it, creating a 
break point in the notational uniformity of the whole development. The Mizar[10] 
library committee has already faced several times these kind of problems, that 
were solved by changing one of the two notations and updating the whole Mizar 
library. 

Among the topics of MKM there are digitalization and enhancement of al- 
ready existing mathematical knowledge. Since the notation used in already ex- 
isting mathematical documents is ambiguous, ambiguity must be addressed in 
both phases. Morever, since the amount of such documents is huge, we should 
minimize as much as possible the amount of disambiguation work left to the 
human. 

In this paper we outline an efficient algorithm which can be used to perform 
ambiguous parsing in applications pertaining to the MKM area. The algorithm 
can be seen as an improvement of the algorithm for ambiguous parsing used in 
type based parsers as the one of the Grammatical Framework [11]. Type based 
parsing imposes a type system over the grammar of the language that must be 
recognized, and uses the typing judgement to prune wrong interpretations. In 
the context of mathematical formulae no additional type system needs to be 
imposed since arity, domain and codomain information associated to mathemat- 
ical operators can play the role of a type system that supports the required 
operations. 
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In Sect. 2 we present the classes of efficient and modular parsing algorithms 
we are interested in; in Sect. 3 we describe refinement, the predicate needed 
to validate formulae fragments; the algorithm itself is presented in Sect. 4 and 
analyzed in Sect. 5, where several future research directions are also outlined; 
final remarks and conclusions are given in Sect. 6. 

2 Requirements 

Traditionally, compilers have been implemented as pipelines of phases. The first 
phase, lexing, takes in input a stream of characters and produces as output a 
stream of tokens. These tokens are the input for the parsing phase which in turn 
produces as output one or more abstract syntax trees (or ASTs for short). The 
semantic analysis phase finally takes in input ASTs and enriches their nodes 
with semantics information. Each phase can fail, aborting the whole process. 

The parsing phase is in charge of recognizing if the input phrase pertains to 
a predefined grammar or not. This grammar is said to be unambiguous if, for 
any given input phrase, there exists at most one AST; otherwise the grammar 
is an ambiguous grammar. 

The output of the parsing phase for an unambiguous grammar is either a 
parse error or the unique AST for the input formula. This property does not 
hold for ambiguous grammars. In that case the output of the parsing phase is 
no longer a single tree, but rather a set of trees. 

Ambiguous grammars are just one aspects of ambiguity, the other one we 
will consider is introduced by the semantic analysis phase. We say that an AST 
is an ambiguous AST when the semantic analysis phase can associate to it more 
than one semantics - whatever the semantics is. 

When this kind of ambiguity has to be considered, the output of the semantic 
analysis phase is a set of semantics for each AST in the input set. Let us consider 
the formula (1 + 2) *3“^ = 1, and suppose we are in the applicative area of proof 
assistants. This formula exhibits the latter aspect of ambiguity described, since 
each symbol in it can have many different semantic interpretations: 

1. each number can be a natural, integer, rational, real or complex number; 

2. “—1” can either be the application of the unary operator ” to 1, or the 
integer, rational, real or complex number —1; 

3. “=” can represent many different equalities (Leibniz’s polymorphic equality 
an equivalence relation over natural or real numbers, . . . ); 

4. “+” and can be defined over naturals, integers, . . . ; 

5. if subtyping does not hold, implicit coercions can be inserted to inject a 
number of one type in a “super type” ; 

6. since different representations of a concept have different computational 
properties, several representations of, say, natural numbers may be avail- 
able. 

Similar observations can be made in applicative areas other than that of proof 
assistants. For instance, some of them applies directly to CASs. In the rest of 
the paper we want to address the two forms of ambiguities at the same time. 
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We say that an algorithm performs ambiguous parsing when it associates to 
an input formula E the set of all the semantics for E. This means that we are 
considering the second and third phases of a traditional compiler as just one 
macro phase. The motivation is efficiency: we want to be able to detect seman- 
tically wrong formulae already during the parsing phase, without generating a 
multitude of ASTs that later on cannot be assigned any meaning. 

At the same time, we do care about the modularity induced by the distinc- 
tion of the two phases. Thus these are the two requirements that we want our 
algorithm to satisfy: 

1. The algorithm should be compositional: the semantic analysis phase should 
be as separate as possible from the parsing phase. 

2. The algorithm should be efficient: semantic errors must be detected as early 
as possible, preventing further parsing and semantic analysis of already in- 
correct interpretations. 

The apparent conflict between the two requirements manifest itself in im- 
plementations that fulfil one requirement sacrificing the other. For instance, let 
us consider again the formula (1 -I- 2) * 3“^ = 1. The naive compositional al- 
gorithm (NCA for short) performs parsing first, returning a huge set of ASTs, 
one for each combination of the possible interpretations of each symbol. For in- 
stance, one possible output is the tree whose root is equality over real numbers 
and whose second argument is the Peano number 1. Then semantic analysis 
proceeds at pruning out the most part of the combinations: for instance, every 
tree whose root is the equality over real numbers and whose second argument is 
not a real number is pruned. Unfortunately, this algorithm is not efficient, since 
several trees are parsed and analyzed even if looking at the root and its second 
argument already provides enough information to prune them out. However, due 
to its triviality, NCA is the most commonly used algorithm [11]. 

Let us now consider the most efficient top-down algorithm, which generates 
every possible interpretation for the root, and for each interpretation calls itself 
on the two arguments remembering what the expected type of the argument 
was. The expected type is used to pick for the second argument of the root the 
only interpretation that respects the type. Corresponding efficient bottom-up 
algorithms can be easily built as well. Clearly this algorithm is not compositional, 
since it performs type checking already during the parsing phase, and just on a 
fragment of the tree. 

In Sect. 4 we propose a compositional and yet efficient algorithm for am- 
biguous parsing of mathematical formulae, showing that the conflict is only 
ephemeral. The main assumption underlying the algorithm is the availability of 
the refinement operation described in the next section. Intuitively, the function 
allows to detect semantic errors on partial ASTs and thus it can be used already 
during the construction of the AST set that is the output of the parsing phase. 

To the authors knowledge the algorithm is new, despite its apparent simplic- 
ity. Its novelty was also confirmed by private communication with Aarne Ranta, 
who is the main author of Grammatical Framework (GF) [11] and without any 
doubt one of the major experts in this field. 
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3 Refinement 

The crucial ingredient of our parsing algorithm is the function that performs 
semantic analysis of the abstract syntax tree of the formula. Its goal is to detect 
invalid formulae. Since the most common mistake in a formula is the application 
of an operator to arguments outside its domain, this function is likely to be a sort 
of type deriver. Indeed, every foundational system used to encode the formulae 
has its own version of a (weak) “type” system. 

Let us consider several kind of formulae encoding used in the mathematical 
practice and in MKM. Set theory is the most widely used foundation among 
mathematicians. In principle, every operator in set theory is untyped (or uni- 
typed), since every term is a set and set theoretical operations can be applied to 
any set. For instance, the natural number zero can be defined as the empty set 
and the natural number one as the set {0}. Thus the formula 0 G 1 is perfectly 
valid. Notwithstanding this, mathematicians that work in set theory use to con- 
sider natural numbers as a sort of abstract data type, forgetting their concrete 
definition and considering “well typed” only the applications of operators whose 
domain is the same or a subset of the set the argument belongs to. 

The logical foundation that Computer Algebra Systems are commonly based 
on is some variant of multi-sorted first order logic. The arity and sorts of the 
symbols define the type system that prevents wrong applications inside formulae. 

The type system becomes a truly first class citizen in mathematical reasoning 
tools based on type theory. The majority of Proof Assistants (PA), with the 
significant exception of Mizar[10], are based on type theory, where a type is 
assigned to every term, and a product (or arrow type) is assigned to operators. 
The application is well-typed if the type of the argument matches the domain 
of the product. 

Type systems can be classified according to the presence or absence of de- 
pendent products. A non-dependent product T\ T 2 types functions whose 
output type T 2 does not depend on the actual argument. On the contrary, a 
dependent product Ux : T\. T 2 {x) types functions whose output type T 2 {x) is 
a function of the actual argument x. Dependent type systems allow to express 
tighter constraints on the arguments of an operator, rejecting a larger number 
of wrong formulae and making the disambiguation algorithm more effective, but 
also more complex. 

Type derivers are programs that check whether a type can be assigned to 
a formula, and that can optionally return the computed type. Thus they can 
be exploited as pruning functions for NCA: after generating every AST, the 
type deriver is used to prune invalid ASTs. To implement our efficient version of 
the algorithm we need an extension, called refiner, of a stronger version of the 
type deriver able to deal with incomplete formulae. However, our algorithm is 
fully generic, since it is not based on a particular calculus or a particular type 
system. The only necessary requirement is the possibility to represent incomplete 
formulae and the existence of a refiner. 

An incomplete formula is a formula where non linear placeholders for subfor- 
mulae occur. Every non linear placeholder 7^ where i is a natural number replaces 
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the occurrence of a subformula. Occurrences of equal placeholders replace equal 
subformulae. In type theory literature, placeholders are called metavariables [8, 
13,7]. 

In type theory for instance, to obtain a typed calculus with metavariables 
from a typed calculus of closed terms (where no metavariable occurs), metavari- 
able occurrences are added to the term grammar, and a typing context for 
metavariables is added to the typing rules. The typing context associates a type 
to each metavariable, that is the type of the term replaced by the metavariable. 
In the case of dependent products, the type of the metavariable in the typing 
context is replaced by a sequent, that describes the type of the replaced term 
and the free variables that (may) occur free in the replaced term, together with 
their type. For instance, the formula Va; : Z.a; =?i is well typed if the sequent 
a; : Z h?i : Z is associated with ?i, stating that ?i is a term of type Z parametric 
in X also of type Z. 

Definition 1 (Refiner). A refiner is a function whose input is an incomplete 
formula t\ and whose output is either: 

— an incomplete formula t 2 where t 2 is a well-typed formula obtained by assign- 
ing a type (or a sequent) to each metavariable in ti and, in case of dependent 
types, by instantiating some of the metavariables that occur in t\; 

— the special constant e if there exists no well-typed formula t 2 that can be 
obtained by assigning a type (or a sequent) to each metavariable in t\ and 
by instantiating some of the metavariables; 

— the special constant _L when neither one of the two previous cases can be 
verified by the algorithm. 

Whereas type checking is usually decidable, refinement is usually a semide- 
cidable problem. Thus, in the literature, refinement algorithms are usually de- 
scribed to return either a refined term t 2 or the T answer [7]. In the Ph.D. thesis 
of the first author of this paper [12] an algorithm that returns the three previous 
answers is described as a simple modification of the classical algorithm. Notice 
that if refineff) = T then no information is actually provided: the formula could 
either be refinable or not. As a consequence, our disambiguation algorithm can 
only exploit the other two answers, and the refiner will be more and more useful 
as long as it minimizes the number of T outputs. 

A simple example should clarify the usage of the refinement algorithm. Let 
us consider the incomplete mathematical formula ?i = represented in set 
theory and in a type theory of total functions with dependent products, and 
let’s try to refine it. We use juxtaposition for operator application, following the 
usual A-calculus convention. 

— Set theory: ?i = is encoded as (= ?i {sqrt I 2 )) where = is the poly- 
morphic equality over arguments that belongs to one set and sqrt is a func- 
tion whose domain is the set K)]" of non negative real numbers and whose 
codomain is the set M of real numbers. 

refine{= ?i {sqrt ? 2 )) returns (= ?i {sqrt ? 2 )) since the term is well- 
typed once the type K is assigned to ?i and the type Kq is assigned to 
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— Dependently typed type theory of total functions: ?i = is encoded as 
(= ?3 ?i {sqrt ?2 ?4)) where = is the monomorphic ternary operator whose 
first argument is a type and whose other arguments are terms of that type; 
sqrt is the binary operator whose first argument x is of type K and whose 
second argument has dependent type (> x 0 ) (i.e. it is a proof of x > 0 ). 
refine{= ?3 ?i {sqrt ?2 ?4)) returns (= K ?i {sqrt ?2 ?4)) since the term is 
well- typed once that ?3 is instantiated with K, the sequent h?i : K is assigned 
to ?i, the sequent h?2 : Kj is assigned to ?2 and the sequent h?4 : (> ?2 0 ) 
is assigned to ?4. 

Notice that, in the case of dependent type theories, the refiner sometimes 
needs to instantiate metavariables that occur in the argument of an operator 
whose type is a dependent product. For instance, in the previous example the 
type of the monomorphic equality is IIT : Type. T T ^ Prop and ?3 is the 
argument of the formal parameter T. Thus the type K of the third operator ar- 
gument {sqrt ?2? 4) must match the type T = 7 3 and this holds only instantiating 

?3 with M. 

In the next section we will describe our disambiguation algorithm that is 
based on refinement instead of the simpler type derivation. 



4 The Algorithm 

Our algorithm for efficient ambiguous parsing is based on two components: a 
parser and a disambiguator. The parser component is similar to the homonymous 
phase of a traditional compiler pipeline in the sense that it actually checks if the 
input token stream belongs to a given grammar. The main difference with a 
traditional parser is that this one, instead of returning a set of ASTs, acts lazily 
immediately returning a pair. The first projection of this pair is a description of 
the choices which have to be made in order to obtain a term (i.e. an unambiguous 
interpretation of the input). We call such a description an interpretation domain. 
The second projection of the pair returned by the parser is a function that returns 
a term once applied to an oracle (called interpretation) that guides its choices. 

The second component of our algorithm, the disambiguator, “drives” the 
parser by feeding with interpretations its output. Interpretations can be totally 
or partially defined over the interpretation domain. When the parser is faced with 
a choice that is not considered in a partial interpretation, it generates a place- 
holder. A partial interpretation approximates a total one since the generated 
open term matches the closed term of the total interpretation. The disambigua- 
tor builds total interpretations by repeated approximations, using the refiner 
described in Sect. 3 to prune those approximations that lead to not well- typed 
terms. 

The clear distinction between parser and disambiguator ensures that our 
algorithm is compositional; the efficiency is in turn granted by the refiner which 
permits to prune interpretations as soon as they lead for sure to not well-typed 
terms. Let us analyze more formally the ideas sketched so far. 
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Let T be the set of well formed terms and let 5 be a set of symbols that can 
have more than one interpretation (that we call choice) in the input. 

Definition 2 (Interpretation). Interpretation domain, interpretation co- 
domain and interpretation are mutually defined in the following way: 

— an interpretation domain is a finite set whose elements are couples (s, 1) 
where s (the symbol to be interpreted) is an element of S and I (the list of 
possible choices) is a list of functions from interpretations to T; 

~ an interpretation codomain is a set whose elements are either the element 
(implicit term) or functions from interpretations to T; 

“ an interpretation is a total function from interpretation domain to inter- 
pretation codomain, subject to the following condition: for each element i = 
(s, [<i ; ; tn]) of the interpretation domain, if the interpretation applied 

to i returns a function t, then t € {ti, . . . t„}. 

An interpretation is partial when there exists an interpretation domain 
item i such that 4>{i) = ?. 

In ML notation Def. 2 is: 

type symbol (* abstract data type *) 

type term (* abstract data type *) 

type interpretation_domain_item = 

Item of symbol * (interpretation -> term) list 
and interpretation_codomain_item = 

Implicit 

I Term of (interpretation -> term) 
and interpretation = 

interpretation_domain_item -> interpretation_codomain_item 

Intuitively, an interpretation domain item describes all the possible ways to 
interpret a given symbol. An interpretation codomain item is either an implicit 
term (refusal of choosing an interpretation for the symbol) or just one interpre- 
tation among the possible ones. Thus, an interpretation is just a kind of oracle 
that, given a set of choices and a set of answers for each choice, associates to 
each choice either an answer among the one proposed or the “no choice” term. 

We let D range over interpretation domains, </> range over interpretations and 
fi over functions from interpretations to terms. Let us now define the parser. 

Definition 3 (Parser). A parser is a function that maps its input (a token 
stream) to a couple where D is an interpretation domain and fi is a 

function from interpretations defined over D to terms. 

Operationally, the parser can be obtained mechanically from a traditional 
parser for non-ambiguous grammars, either top down, bottom up, or general, 
by lifting its output from terms to functions, from interpretations to terms. An 
example in OCamlYacc^ syntax should clarify the previous statement. Let us 



^ OCamlYacc is a tool, similar to Yacc, that produces bottom up OCaml parsers from 
LALR(l) grammars. 
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consider the OCamlYacc production that parses the formula tl (the factorial of 
t) and returns an OCaml value representing the resulting term: 

expr: expr BANG { Bang ($1) } 

Applying the mechanical lifting transformation, the production becomes: 
expr : 

expr BANG { 

let dom, mk_expr = $1 in 

dom, fun interp -> Bang (mk_expr interp) } 

The first component of the output is the domain of the subexpression. The 
second component is a A-abstraction over an interpretation, that becomes the 
argument of the subexpression (that is now lifted and needs an interpretation in 
input). 

The interesting case is the case of ambiguous parsing, i.e. the case when the 
parser must make a choice. The solution is simply to add all the possible choices 
to the output domain, and makes the interpretation function perform the choice. 
Example: 

expr : 

expr EQ expr { 

let ((doml, mk_exprl) , (dom2, mk_expr2)) = ($1, $3) in 

(union (union doml dom2) 

(EQ, 

[ fun interp -> (* decidable equality over naturals *) 

APPL [eq_nat ; mk_exprl interp; mk_expr2 interp]; 
fun interp -> (* leibniz’s equality *) 

APPL [eq; ?; mk_exprl interp; mk_expr2 interp] ])), 

fun interp -> 

match interp EQ with 

I Implicit -> ? (* fresh metavariable *) 

I Term mk_term -> mk_term interp } 

If the oracle interp given in input satisfies Def. 2, then interp EQ will be 
either Implicit (refusal to choose) or one of: 

1. Term (fun interp -> (* decidable equality over naturals *) 

APPL [eq_nat; mk_exprl interp; mk_expr2 interp] ) 

2. Term (fun interp -> (* leibniz’s equality *) 

APPL [eq; IMPLICIT; mk_exprl interp; mk_expr2 interp] ) 

From the latter example it should be clear in which sense the parsing phase 
proceeds “lazily” and also in which sense interpretations behave as oracles for 
the parsers. The last and more interesting component is the disambiguator. 

Definition 4 (Disambiguator). A disambiguator is a function whose input 
is a couple (D,t^) where D is an interpretation domain and a function from 
interpretations defined over D to terms. The output of the disambiguator is the 
set {t I 3(j) of domain D s.t. t = t^{4>) and t is well-typed} 
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All the couples parser, disambiguator are clearly compositional. We will now 
present an efficient algorithm satisfying the specification for a disambiguator. 
The idea of the algorithm is to build the set of interpretations that produces 
well-typed terms by progressive refinements, starting from the interpretation 
that always refuses to choose and progressing towards an interpretation that 
always returns some lifted term. At each refinement step, the function is 
applied to obtain an open term, that is immediately fed to the refiner. The 
refiner function acts as a sort of validator, rejecting partial instantiations that 
already produce ill-typed open terms. In the case of dependent types it may also 
provide positive information, in the sense that it may automatically instantiate 
several metavariables, constraining the set of future choices. 

The simplest version of our algorithm - that does not exploit refiner positive 
information - can be sketched in pseudo-code as follows: 



let refine (t) = a refiner according to Def. 1 

let = f = '. 

I 1^ (j){sj otherwise 

let disamhiguate{D,^) = 
let 00 = \x. Implicit 

d> - / refine(ti;{fio)) yf e A re/ine(t|(0o)) 7^ -L 

^ 0 otherwise 

foreach (s, 1) G D 

:= {0' I 0 € ^ A t'l G I A (j)' = update{4>, s, t'^) A refine (t^ {(p')) e} 
return {0 | 0 G A refine{t^{(j>)) T} 



The following is an example of the application of the algorithm to the formula 
(5/2)! where / can be either the integer division /n or the real division /r, 2 and 
5 can be natural or real numbers and the factorial operator can be applied only 
to natural numbers. Only the first iterations of the main loop are reported. 




: nat 



nat 



[2 : nat ; 2 : R] 
[5 : nat ; 5 : R] 
Implicit 
Implicit 
Implicit 



Implicit 

Implicit 



nat ; /r : R ^ R ^ R] 



re/me(t|( 0 o)) = 

re/me(?i!) = {?i : nat} 



re/me(t|( 0 i)) = 

re/me((?i/N?2)0 = {?i : nat ; ?2 : nat} 



f / /b 

0} = < 2 1 -^- Implicit 
[ 5 1-^- Implicit 

= {0l} 



re/ine(t|( 0 i)) = 

re/me((?i/R?2)!) = e 
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5 Analysis and Futnre Improvements 

The algorithm presented in the previous section is surely efficient according 
to our notion of efficiency since at each iteration of the for loop the set of 
interpretations {</>' \ 4> € € I A (p' = update{4>, s, t'|)} is immediately pruned 

by means of the check refine(ti;{(p')) yf e. Pruning prevents further parsing of the 
user provided formula (since parsing is a lazy operation) and reduces the number 
of applications of the semantic analyser (the refiner in our implementation). More 
formally, we can try to estimate the computational complexity of the algorithm 
in order to compare it with that of NCA. 

Estimating precisely the cost of the parsing phase is very complex since it 
is interrupted by pruning. Moreover, the overall time spent by the algorithm is 
dominated by the semantic analysis. Thus we ignore the parsing time and we 
define the computational cost of the algorithm as a function of the number of 
calls to the refiner. 

Let (Pi be the value of the ^ variable at the i-th loop of the algorithm. The 
number of refine operations invoked is 

The worst case of the algorithm is obtained when pruning always fails. Thus 
> I^dI = The latter formula is the number of abstract 

syntax trees computed by NCA. Thus, in the worst case, our algorithm is more 
expensive than the NCA. However, the worst case is extremely unlikely when 
|Z?| is big, since it corresponds to a term where a lot of ambiguous symbols occur 
with the following property: each symbol is completely independent of the others 
and it can be resolved independently from the other choices. 

The optimal case of the algorithm is obtained when pruning reduces the set 
{(j)' \ (j) G < 1 > A G I A (j)' = update{(p,s,t'^)} to a set of cardinality c where c 

is the number of valid interpretations. Thus = c\D\. Since c 

is usually a small value - how many different valid interpretations of a formula 
usually hold? - the latter expression is smaller than 77(5 already for small 

values of \D\, and it becomes smaller and smaller when |7?| (the number of 
ambiguous symbols in a formula) increases. 

It is now evident that the computational complexity of the algorithm is 
greatly influenced by the pruning rate: the more invalid partial terms will be 
detected, the smaller the |^i|, the lower the overall time spent by the algorithm. 
In particular, to obtain an average performance close to the optimal case we 
should minimize |^i| for each i by pruning invalid interpretations as early as 
possible. 

The choice of the strategy used to pick the next element of the domain D 
in the foreach loop of the algorithm greatly influences the pruning rate. Let us 
consider the following trivial example: (/ {g x) {h y)) where all the atoms are 
ambiguous (i.e. f,g,x,y are all elements of the disambiguation domain D). 

The strategy that sorts D according to the visit in preorder of the syntax tree 
refines in succession the terms (/ ?i I2), (/ (5 ?s) ?4), (/ {g x) I4) and so on. 
Since the type of a function constraints the type of its arguments, refining the 
first term already rejects interpretations of / that are not binary, and refining the 
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Table 1. Comparison between our algorithm and NCA 
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NA = Trivial compositional algorithm (number of refinements) 
PA = Proposed algorithm (number of refinements) 

I = Improvement = NA — PA 



second term rejects interpretations of g whose output type does not match the 
type of the first argument of /. Thus at each step several partial interpretations 
are pruned. If the type of the function constraints the possible interpretations of 
the operands to just the choices that are prefixes of the final valid interpretations, 
then we are facing the optimal case of the algorithm. 

Any other strategy that consider a subterm without first considering its par- 
ents in the abstract syntax tree yields to less pruning. For instance, the term 
(/ (?5 x) (?6 y)) can be successfully refined for each interpretation of /, x and 
y such that / is a binary operator. The reason is that the refiner can always 
attribute to ?s the type Ti ^ T 2 where Ti is the type expected by / and T 2 is 
the type of x. 

The strategy that sorts D by preorder visiting the syntax tree is not always 
optimal, but it behaved particularly well in all the benchmarks we did on our im- 
plementation, exhibiting an average case really close to the optimal one. Table 1 
compares the number of invocations of the refiner using our algorithm and using 
NCA. The table has been obtained parsing all the statements and definitions of 
all the theorems that deals with real numbers in the standard library of the Coq 
proof assistant. 

As expected our algorithm performs more refinements than NCA when the 
number of ambiguous symbols - and thus also the number NA of syntax trees - 
is small. In this case only a few more refinements are performed. When the size 
of the domain - logarithmic in the number of NA of syntax trees - grows, the 
number of refinements performed by our algorithm grows only linearly in the 
size of the domain. Note that this is the expected behaviour for the optimal case 
of the algorithm when the number of valid interpretations c is fixed. Indeed, only 
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5 of the 79 statements admit more than one valid interpretation. We conclude 
that in practice the average case of our algorithm is close to the optimal case. 

Notice also that there is a trivial heuristic to predict whether our algorithm 
is convenient over NCA: it is sufficient to look at the number NA of syntax trees 
and apply our algorithm whenever NA is higher than a given threshold (32 in 
our benchmark). 

We should further observe that the computational cost of a refinement is not 
constant, being a function of the term to refine, and it is extremely difficult 
to approximate. Still, it is surely small for small terms. Thus the calls to the 
refiner performed by our algorithm are in the average case cheaper than those 
performed by NCA, since at least half of our calls are on prefixes of the syntax 
tree. 

Moreover, using preorder visit, the computational cost of the computation of 
t^{4>) and refine{t^{4>)) can be lowered. Indeed, at each iteration of the for loop, 
is applied to an interpretation that differs from tj) only by instantiating more 
implicit arguments that are leaves of the generated term tree. Thus, the term 
returned by t^{(p) is a prefix of the term returned by This suggests that 

the cost of the computation of (</>') could be greatly reduced by changing 
so that its exploit the knowledge about the partial result Similarly, when 

refine{t^{4>)) is defined and different from T, its value can easily be exploited 
in the refinement of 

Combining these two optimizations, we can easily make the cost of the two 
operations at each iteration negligible, still being compositional. These optimiza- 
tions have not been implemented yet, they are planned as future work. 

Another optimization derives from the positive information computed by the 
refinement function, that is the map that associates a sequent or an instantiation 
to each metavariable. For instance, if the refine operation assigns to ?i the type 
K ^ R, an interpretation that instantiates ?i with logical negation can be 
rejected without even trying to refine the associated term. This corresponds 
to remembering in <!> also the refinement map associated with each term and to 
adding a new pruning test over (j)' based on the unification of the type of the 
term generated by with the type assigned to s in the map. This optimization 
is also planned as future work. 

An interesting topic that was completely skipped so far is the construction of 
the interpretation domain by the parser. MKM tools provide at least two sources 
of information that can be exploited to construct the list of possible choices for 
each symbol. The first one is related to the ambiguities that arise from the res- 
olution of an identifier. Indeed, it is not unusual to have several objects in a 
distributed library that are given the same name (e.g. “reflexive_property” , “do- 
main” or simply “P”). Thus to every identifier we can associate several objects. 
The parser needs to retrieve for each identifier the list of all the objects whose 
name is equal to the identifier. The task can easily be performed making the 
parser consult a search engine for mathematical formulae as the one developed 
in the MoWGLI project [5] or the similar, but less generic one, developed by the 
Mizar group [2]. 
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The second source of information is represented by XML notational files that 
describe the mathematical notation associated with definitions in MKM libraries. 
Indeed, several projects provide XSLT stylesheets to render mathematical formu- 
lae encoded in content level markup as MathML Content, OpenMath or OMDoc. 
Since there exist large classes of operators that share a similar notation, these 
stylesheets are usually generated from more concise descriptions of symbols arity 
and precedence levels [9,4,6]. These descriptions could be exploited also in the 
implementations of our disambiguation algorithm. 

Finally we should address the case where the disambiguator returns more 
than one well-typed term. Depending on the kind of processing required on the 
terms, the system may either proceed in parallel on all the generated terms, or 
ask the user to choose the term she was interested in. In the latter case the 
system can identify all the choices that are still ambiguous, and present to the 
user a human readable description of each choice. 



6 Concluding Remarks 

Our disambiguation algorithm has been implemented and integrated both in 
the MoWGLI search engine and in the HELM proof assistant prototype [12]. 
The former is a Web-Service for retrieving lemmas and definitions from the dis- 
tributed HELM library by matching their type against a user provided pattern. 
The lemmas and definitions are XML encodings of those in the library of the 
Coq proof assistant [3] . We developed a Web interface for the search engine that 
allows users to enter patterns as mathematical formulae with placeholders. 

The usual mathematical notation is available and it is disambiguated using 
our algorithm. In case of multiple interpretations of the formula the search engine 
can ask the user to identify the only interpretation she is interested in, or it can 
perform the search according to each interpretation. For instance, it is possible 
to look for theorems stating ?i-l -?2 =? 2 +?i retrieving at once the commutative 
property for the addition over Peano natural numbers, binary positive numbers, 
integers, rationals and real numbers. 

The performance analysis presented in Sect. 5 is confirmed by our implemen- 
tation: the time spent in the disambiguation of the formula is negligible with 
respect to the time spent in the search and in the network transmission. 

The HELM proof assistant prototype implements an interactive reasoning 
tool based on the logic of Coq, adopting the HELM distributed library as its 
own library. One main difference with respect to the Coq system is the size of 
the context. Whereas in Coq the context corresponds to only a subset of the 
whole library, in our prototype all the definitions and theorems in the library 
are in scope. Thus we must face a much higher degree of ambiguity, since several 
mathematical notions have been redefined several times in the library of Coq 
and since there exists several formalizations of the same mathematical concept. 
Another important difference is that Coq behaves as a compiler, whereas our tool 
is more interactive. Thus every Coq input must have exactly one interpretation, 
since in case of multiple valid interpretations it is not possible to ask to the 
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user what interpretation she meant. We observed that disambiguation time is 
negligible with respect to the validation time of a single proof step. 

Comparing our solution with that adopted in the forthcoming release of the 
Coq system (version V8.0) is surely interesting. Whereas in the previous versions 
of the system the grammar did not allow overloading, in version 8.0 overloading 
is admitted thanks to the introduction of notational scopes. A scope is a region 
of text where only some parsing rules are active. For instance, there exists a 
scope where is interpreted as the multiplication between Peano numbers and 
another one where it is interpreted as the product of two types. A syntactical 
device is given to the user to change the current scope, even in the middle of 
a formula. Scopes are associated with the arguments of the constants, so that 
when an argument of type Set is met the scope that handles as a type 
product is opened. 

The reader should notice that associating a scope to a constant argument 
is weaker than associating a scope to the type expected for an argument. For 
instance, the identity function id has type ilT : Set.T T and {id nat 0) is a 
correct application where the type T is instantiated with the type nat of natural 
numbers, and 0 has the expected type T = nat. However, associating the scope of 
natural numbers notation to the second argument of id independently from the 
value of the first argument is a mistake. More generally, we observe that scopes 
behaves as a new kind of types, much in the spirit of those of Grammatical 
Framework [11]. This new type system is imposed in parallel with the already 
existent type system of Coq, that is not exploited. On the contrary, our algorithm 
is based on the refinement operation provided by the underlying logic of Coq. 

For sure, one benefit of this duplicate and weaker type system is its generality: 
since it is independent from the underlying logic, it can be made part of the 
notation description and it can be reused with several backends. Nevertheless, 
there are major drawbacks. First of all, as shown in the previous examples, 
disambiguation is less effective than that based on our technique, since scopes 
are chosen by exploiting the context only in a minimal way. More explicitly, 
imposing a weak type system when a stronger one is available is not appealing 
at all and requires strong motivations that we do not see. 

Secondly, there is a problem of consistency between the two type systems: 
since the notational types are assigned by the user without any consistency 
check, it may happen that a wrongly assigned notational type prevents the user 
from inserting valid Coq terms. Adding another layer of consistency checking is 
both theoretically and practically complex, especially when compared with the 
simplicity of the algorithm proposed in this paper. 
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Abstract. This paper describes technologies to create and maintain a 
problem solving environment based on a framework for distributed math- 
ematical web services. Our approach allows clients to access mathemat- 
ical computational facilities through a uniform set of network protocols, 
independent of the software packages that provide the end functionality. 
The author of a mathematical web service need know only the specifics of 
the system in which the mathematical computations are performed, e.g. 
Maple, Mathematica or Fortran with NAG library. Whatever additional 
network service code that is necessary (e.g. Java, wsdl, etc), is generated 
and configured automatically. This paper presents a brief architectural 
overview of the entire framework, and then gives a detailed description of 
the design and implementation of the tools for mathematical servers for 
this environment. A set of mathematical web services currently deployed 
are described as examples. 



1 Introduction 

Over the past decades mathematical software systems have become increasingly 
powerful and complex. Each major system has its own strengths and areas in 
which it surpasses the others, often provided by complex packages or libraries. 
This picture changes constantly as new versions of systems are released. Consid- 
erable expertise required to know which package is the best for which problem at 
any given time. Users are therefore often unaware of existing software solutions 
to their mathematical problems. Even if they are aware they may not be willing 
to maintain up-to-date licenses for multiple software systems only occasionally 
used. We see this situation becoming more challenging over time, and its solution 
is the object of the monet project. 

MONET is a European esprit project for Mathematics On the NET, with the 
goal of designing a framework for the provision and brokerage of mathematical 
web services. The partners in this consortium are the Numerical Algorithms 
Group Ltd (NAG), the University of Bath, Stilo Technology Ltd, the University 
of Manchester, the Technical University of Eindhoven, the University of Nice, 
and the Ontario Research Centre for Computer Algebra at the University of 
Western Ontario. The architecture devised by the monet consortium involves 
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(1) a number of software components, including brokers, planners and servers, 

(2) various ontologies representing mathematical problem domains and services, 
and (3) specific languages to communicate mathematical problems, results and 
explanations. An overview of this architecture is given in Section 2, and a detailed 
description is given in the report [1]. While the best approach for service brokers 
and planners remains the subject of on-going research, the strategy for providing 
the specific mathematical services can be declared complete. This is the main 
subject of the present paper. 

We have developed an approach whereby (1) the author of a mathemati- 
cal web service need know only the software system he or she uses to provide 
the service, and (2) the user of the mathematical service need not be aware 
of the implementation language. For example, an expert in symbolic computa- 
tion, proficient in Maple, can develop a set of Maple packages solving a specific 
problem. This expert can then use our framework to create a mathematical web 
service to solve this problem. Without additional effort on the part of the service 
author, the service will accept requests in a system-neutral protocol, based on 
OpenMath [9] [10]. We describe this architecture for mathematical web services 
in Section 3. A number of issues arising in the implementation are described in 
Sections 4, 5 and 6. 

We believe that both services and clients benefit from this architecture. 
Clients do not have to have the necessary mathematical software installed lo- 
cally, and are not required to know the syntax and calling sequences of multiple 
mathematical software packages. Service providers can expose their most recent 
mathematical software to a larger target audience, reduce maintenance costs for 
old versions, and potentially derive transaction-based revenue. Once a sufficient 
number of services are deployed, the monet framework could be applied to a 
wide spectrum of applications, including professional technical services, mathe- 
matical education and distance learning, and research support in a number of 
domains. As mathematical systems become ever more complex, this approach 
to service discovery and planning could conceivably be used within individual 
systems. 

In order to place our work in context in the world of mathematics-related web 
services, we refer to some other projects in this area, including MBase [25] and 
H-Bugs [11]. MBase is a extensive database for mathematical theory, symbol, 
definition, axiom and theorem. It contains a variety of mathematical knowledge 
description, but does not particularly aim to offer any implementation of al- 
gorithms or methods for the solution of mathematical problems. H-Bugs is an 
investigation to distributed system based on monet architecture, as demon- 
strated, for theorem proving. The main topic of this paper is the description of 
the architecture for providing mathematical computation web services within the 
MONET framework. 

As a first example, we have developed and deployed the following symbolic 
mathematical web services at University of Western Ontario ^ (see Fig. 1): Arith- 
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Fig. 1. MONET web services page at University of Western Ontario 



metic expression simplification, Indefinite integration, Definite symbolic inte- 
gration, Definite numeric Integration, Ordinary differentiation. Fractional-order 
differentiation. Symbolic-order differentiation of rational functions. Limit cal- 
culation, Series expansion. Approximate GCD, Root-finding service (including 
parametric solutions) and Solving systems of polynomials. 



2 General monet Architecture 

2.1 Main Components 

There are three components in monet architecture: client, broker and server (see 
Fig. 2). Servers expose their services by registering with brokers. Clients send 
queries to a broker asking if web services for solving specific kinds of mathemati- 
cal problems are available. Brokers resolve clients’ queries by looking for suitable 
mathematical services available and passing the clients’ requests to them. After 
this, services try to solve the given mathematical problems using the capacities 
of their mathematical solving engines. Finally, clients obtain the result of the 
computation and possibly a meaningful explanation. 

2.2 Mathematical Broker 

The Mathematical Broker presented in [5] is a special component in this ar- 
chitecture. It is assumed to be a sophisticated search engine and planner for 
complex mathematical problems. Its goals are to match the characteristics of 
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Fig. 2. The general scheme of the MONET Architecture 




Fig. 3. The general scheme of the MONET Broker 



given mathematical problem to web services available and, if no single service 
can solve the given problem by itself, to divide the problem into smaller por- 
tions that can be solved by available services. In general, matching requests for 
arbitrary mathematical problem is intractable. However, we seek to provide a 
solution for a wide range of problems that appear in practice. 

2.3 Languages and Standards Used 

Languages and standards have been developed by the OpenMath society and 
the MONET consortium to describe mathematical problems and communicate 
the results in an unambiguous way. OpenMath [9] [10] is an extensible standard 
to encode the semantics of mathematics in a system-neutral format. It was cho- 
sen for communicating mathematics in this architecture because, unlike Content 
MathML, it can be extended natively to cover new areas of mathematics by writ- 
ing new Content Dictionaries. The Mathematical Service Description Language 
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(MSDL)[4] is a specialized format that describes mathematical web services in 
the MONET architecture. It is needed when servers register the services with bro- 
kers. There are others languages developed by MONET consortium, but these two 
are used by servers to expose and provide services. 

3 Architecture of Mathematical Web Services 

In the MONET architecture mathematical web services are provided without re- 
vealing their implementation structure. A mathematical web service can be pro- 
vided by a stand-alone C program, or by an interface to a package from a system 
such as Axiom[22], Derive[23], Maple[20], Mathematica[21] or Matlab [24] . This 
approach aims to be flexible and extensible, to allow easy switching between 
mathematical systems, and to allow the easy creatoin of new services. 

In this section we describe the architecture we have designed for the con- 
struction of such a Mathematical Web Server. In our description we show the 
service being provided by a Maple program, but in principle any other package 
could be used. 

3.1 Mathematical Web Server Environment 

The first design decision for the Mathematical Server is that all services de- 
ployed on it to run independently, each reachable at its own unique URL and 
offering its own functionality. All of these services are enclosed within a specially 
designed software package, sometimes called the wrapper tool, and may be main- 
tained by several managers. Together, these form the Mathematical Weh Server 
Environment. 

One of the essential components to the Mathematical Web Server is its math- 
ematical engine, usually provided by a a package within some computer algebra 
system. 

The general scheme of organization for the Mathematical Server is shown in 
Figure 4. It shows that each mathematical service is assigned to several compo- 
nents, which all together are responsible to fulfill service’s functions. 

The principal information about each service is provided by the service con- 
figuration file that contains tree parts: (1) a formal service description, using 
MSDL [4], (2) a service interface to a mathematical software system, and (3) an 
actual service implementation provided as code for that system. It is possible 
for alternative implementations to be given, in which case parts (2) and (3) have 
multiple components. 

The wrapper tool is a container for a generic mathematical service, and its 
specific behaviour is determined by the service configuration file. 

Outside the mathematical engine, there are two core managers to maintain 
the network interface to this mathematical server environment: one is responsible 
for new service creation and installation, and the other for invocation of a service 
installed. 
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Fig. 4. The general scheme of monet Mathematical Server Architecture 



3.2 Mathematical Service Organization 

Mathematical Services are organized in such a way that the author of a new 
service need not know about web servers and services, Java or the various XML 
technologies in order to create a new service. Instead, the service’s authors pro- 
vide code written for a mathematical system that implements their service. The 
author must separately indicate the name of the main function that enters this 
implementation. 

As shown in the Figure 4, each service is associated with three original pieces 
of information and three generated components. The original information about 
the service includes the formal service description given in MSDL, service inter- 
face to the mathematical engine of the server and code for the service imple- 
mentation to be executed by mathematical engine. Generated associates of the 
service are service core Java class, web service deployment descriptor (WSDD) [8] 
and web service description language file (WSDL) [7]. 

Service Configuration File. The original information about a mathematical 
service is provided by the service author and stored in an XML-based configu- 
ration file. This file is the item in the mathematical service infrastructure that 
uniquely and completely represents the service implementation. 

The service description file consists of three parts: the service MSDL skeleton 
(to be completed automatically during service installation), service interface to 
mathematical engine (for example Maple or Axiom), and service implementation 
(code written in the language of the mathematical system used). 

The structure of the configuration file has the pattern indicated below.: Note 
that a file may contain descriptions for more than one service, especially if it 
makes sense when several services share parts of an implementation. 
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<mathServer> 

<msdl> 

<service name="sevice_A"> 

{MSDL skeleton for service A} 

</ service> 

{MSDLs for other services} 

</msdl> 

<services> 

<service name="service_A" call="function_call_f or_service_A"/> 
{interface for other services} 

</ services> 

<implementation language = "math_solver_name"> 

{implementation for each service using 
the languageof the corresponding solver} 

</ implementation> 

</mathSever> 

The configuration file for each service should be available for the wrapper 
tool at any time after the service is installed on the Mathematical Server. 

Generated Service Associates. The configuration file statically describes ser- 
vice functionalities. In order to fulfill them dynamically we still need additional 
descriptors and implementation tools. Those components are service implemen- 
tation Java class, WSSD and WSDL files. 

All of them are automatically created by the Mathematical Solver Environ- 
ment installation engine: a Java class is created according to the information 
provided in the service configuration file, then both WSDD and WSDL descrip- 
tors are derived from this Java class API. 

These generated components are then used to deploy, expose and run the 
service. During service installation, the created Java class is placed in a proper 
location in the web server file system, so it is ready to maintain service calls. 
WSDD is used to deploy service on the web server, and WSDL is exposed to the 
outside world to provide monet brokers and clients with the information about 
service interface (see Fig. 5). 

Realization of Service Functions. The main functions of each mathematical 
web service are carried out by a combination of a service core Java class, the 
server Invocation Manager and information from the service configuration file. 

The main idea of the service organization is that its Java class receives all 
requests from the outside (client or brokers), extracts information about math- 
ematical arguments (if any) passed with the request and then calls service invo- 
cation engine. The Invocation Manager in turn creates a program for the solving 
engine in real time, using information from service configuration file and the 
mathematical arguments from the service call. This program is passed to the 
server’s mathematical engine for execution. The result is retrieved by the same 
Invocation Manager, wrapped into a service response message and sent back to 
the client or broker (see Fig. 6). 
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4 Details of the Architecture Implementation 

4.1 Technologies Used 

The list of technologies involved in the process of developing Mathematical Web 
Server includes several network protocols: SOAP [6], TCP, HTTP, etc., various 
products from Apache software foundation: Jakarta Tomcat [16], Axis [17] and 
Ant [18], different computer algebra systems such as Maple [20] and Axiom[22], 
as well as Java SE [14] from Sun Microsystems. 

4.2 Core Components of the Mathematical Web Server 
Architecture 

As mentioned in section 3, the implementation of the Mathematical Web Server 
includes installation and invocation managers. The installation manager takes 
care of new service creation and maintaining (installation/deinstallation). The 
invocation manager is an engine that handles calls to services from the outside. 
There is also a third component of Mathematical Web Server; it is responsible 
for installation of mathematical server itself. 

4.3 Mathematical Web Server Installation 

The Mathematical Web Server installation process sets up a web server in order 
to prepare it for running mathematical web services. 

Assuming Apache Tomcat and Apache Axis are already installed on a web 
server, the procedure of setting it up for monet Web services is performed by 
running a script from the installation kit. 

4.4 Mathematical Web Service Installation 

The Mathematical Service Installation Manager is implemented as a combination 
of Java programs and shell scripts. Each of the Java programs is responsible 
for carrying out one or more steps of service installation process. The whole 
instillation is driven by a manager script. As described in the section 3.2, all 
necessary information about a service is provided in its configuration file. In 
order to install a service, the Installation Manager needs to have access to this 
file. To register a new service with the monet Broker, the Installation Manager 
also requires the URL of the Broker. 

While installing a new service(see Fig. 5), the Installation Manager 

— parses configuration file to extract the information about service interface, 

— creates Java class that will implement the service on the web server, 

— generates server deployment descriptor (WSDD), 

— deploys the service on the web server, 

— retrieves WSDL (descriptor of web service interface to clients) created by 
the server, 

— according to the current service installation, updates its MSDL skeleton to 
a FULLY functional mathematical service descriptor. 
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Fig. 5. MONET Mathematical Service Installation 



After installation is complete the service can be seen from outside by monet 
clients and brokers, and it is ready to handle requests from them. 

4.5 Mathematical Service Invocation 

When a mathematical service receives a request with a mathematical query, the 
service core Java class retrieves the input arguments from this query and calls 
the service Invocation Manager. 

The Mathematical Service Invocation Manager is implemented as a combi- 
nation of several Java libraries and auxiliary packages for mathematical engine 
systems, designed to fulfill service functions according to the information pro- 
vided in the service configuration files. 

The following steps (also shown as scheme in the Fig. 6) are executed every 
time a mathematical service is invoked: 

1. The service Java class calls the Invocation Manager with the following pa- 
rameters 

— the reference to the service configuration file 

— an array of mathematical arguments from the query to the service 

— optional mathematical formats, if client set preference for encoding of 
service input and output (see section 5). 

2. The Invocation Manager parses the configuration file and extracts the service 
implementation and service interface. 

3. The service arguments, by default encoded in OpenMath, get parsed and pre- 
pared for the conversion to the internal syntax of the mathematical engine. 

4. The Invocation Manager generates the program to be executed by the math- 
ematical solving engine. This is based on the implementation part from the 
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Fig. 6. MONET Mathematical Service Invocation 

service configuration file, the service interface to this system and the math- 
ematical arguments from service request. 

5. The generated code is passed to the mathematical engine for execution. 

6. The result from mathematical engine returns to the Invocation Manager. 
There it gets converted to an appropriate mathematical format and encod- 
ing (see section 5.2), afterward it is passed back to service core Java class. 

7. The service Java class wraps the answer into a message using the SOAP 
object exchange protocol and sends it back to the monet client. 

5 Mathematical Web Service Input and Output 

5.1 Input Format 

All MONET mathematical services accept input arguments as OpenMath expres- 
sions. Each expression can be encoded as plain string, an XML DOM object[13] 
or a RIACA OpenMath object[12]. The reason to support all of these encodings 
was to experiment with a choice of possible interfaces to clients and brokers 
while using the same service. 

A string is the simplest way to format a request. This does not require any 
extra libraries, nor serialization tools on a client side. However, in case of string- 
based inputs there is a hight probability of submitting invalid OpenMath within 
service requests. 

An XML Document Object Model (DOM) is used to represent parsed XML 
documents in as a tree structure. It is a moderately more complex encoding of 
OpenMath objects that at least can ensure that the passed arguments represent 
are valid XML. 

The RIACA format is specially designed to represent OpenMath objects. It 
guaranties that inputs sent are valid OpenMath, but in this the case client has 
to know about the RIACA library, have it installed locally and perform the seri- 
alization of RIACA objects when sending SOAP messages with service queries. 
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5.2 Output Format 

The mathematical services currently implemented return string object encoding 
OpenMath expression, containing the list of results or error message. 

MEL Format. If requested by a client, the answer from a service can be 
wrapped in a service response object, using the monet Mathematical Expla- 
nation Language (MEL) [2] ontology. We do not offer this option by default, 
since when the result from a service is sent back to the monet Broker, the later 
will provide the wrapping, possibly including supplementary information, such 
as explanation from a Planning Manager or Execution, etc. 

Additional Mathematical Formats for Service Output. In addition, our 
current implementation of monet mathematical services supports several other 
mathematical formats to encode service results. Users may set their preferences 
while calling a service, and the result can be given in any of the following formats: 
OpenMath, Content MathML, Presentation MathML and LaTeX. This is an 
experimental facility that can be used in environments that integrate several 
formats into represent mathematical objects. 

5.3 Conversion Between OpenMath and Math Engine Language 

Conversion between OpenMath and language of the chosen solvers is important 
in offering mathematical web services. All mathematical expressions must be 
encoded in OpenMath, a system-neutral format, but not all solvers can accept 
input and return output in OpenMath. 

Conversion between OpenMath and strongly-typed languages, such as Axiom, 
is not difficult because type information is apparent in both formats. Conver- 
sion between OpenMath and dynamically typed languages, such as Maple, does 
not have a trivial solution because the semantic information for expressoins in 
these languages is often implicit. It is not practical to force all service authors 
to use only solvers that use strongly-typed languages, because solvers that use 
dynamically-typed expressions can be very useful in practice. We use Maple to 
demonstrate the challenges and our solution in converting between OpenMath 
and a dynamically typed language. Similar issues would be encountered when 
service authors try to offer mathematical web services using another mathemat- 
ical engine having a dynamically- typed language. 

The conversion between OpenMath and Maple is described using a collection 
of Mapping files, typically one for each OpenMath CD in use. Mapping files de- 
scribe the correspondence between OpenMath and Maple, and a single mapping 
file is used to drive both directions of the conversion. An entry in a mapping file 
contains a fragment of OpenMath markup and the corresponding structure of 
Maple command. When designing the mapping files, some differences between 
OpenMath and Maple are generalized. Order of arguments and corresponding 
Maple command are taken into account. If the mapping file’s design cannot be 
used to describe the conversion, a Maple procedure can be attached instead. 

Converting from OpenMath to Maple is mostly straight-forward. The corre- 
spondence can usually be determined by the OpenMath symbol (<0MS>) alone. 
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Difficulties in this direction of conversion still exists because of the differences in 
the design of the languages or in the form of certain expressions.. For example, 
the partial differentiation operation in Maple takes a list of bound variables to 
indicate with respect to which the differentiation is to be done. The correspond- 
ing OpenMath function takes the indexes of bound variables in a list to achieve 
the same purpose. In the worst case, an OpenMath expression may not have a 
Maple correspondence at all. In this case, the converter throws an error notifying 
the users that certain OpenMath symbols are not handled by this converter. 

Maple to OpenMath conversion is less straight-forward because a Maple ex- 
pression is subject to ambiguities. Ambiguities exist in a Maple expression be- 
cause Maple is a dynamically-typed language and the meaning of an expres- 
sion cannot be determined by the symbolic function compositions alone. As a 
simple example. Maple uses the same function call (“diff”) for both univari- 
ate and partial differentiation. OpenMath has two distinct symbols (<DMS>) for 
these mathematical concepts. Some ambiguities can be resolved by inspecting 
the number of types of arguments. For ambiguities that cannot be resolved in 
this manner, we develop and employ policies to specify what to do with such 
cases. The first policy is to resolve the ambiguity by an extra Maple procedure 
supplied when the converter is invoked. An example strategy in this policy is 
to choose first possible OpenMath correspondence found. Second policy is to 
generate a pseudo OpenMath representation that can be dealt with later. In the 
worst case, the third policy is used to throw an error notifying the user that such 
ambiguity cannot be resolved. 



6 Using Other Mathematical Engines with the Server 

As mentioned in section 3.2, different math engines can be used with this ser- 
vice architecture. For the author of the service, switching between mathematical 
engines means only editing the service configuration file. For the developer of a 
Mathematical Server, changing its mathematical engine requires replacing com- 
ponents of the Invocation Manager that are specific to the mathematical software 
used, however the second part of the Mathematical Server ~ Installation Manager 
remains the same. 

6.1 Changes to Service Configuration File 

The configuration file allows an author to specify the name of the mathematical 
engine, and give an implementation for the engine with that name. It also permits 
to have more than one implementation for the same service, using alternative 
mathematical engines. For example the service for definite integration may use 
system Derive, Axiom or Mathematica instead of Maple, or it may use all four of 
them. In this case all that is required from the author of the service is to change 
the implementation part of service configuration file. If one decides to use all of 
the above computer algebra systems to implement definite integration service, 
its configuration file might be re-written as the following: 
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<mathServer> 

<msdl> 

{ MSDL for Definite Integration Service }■ 

</msdl> 

<services> 

<service name="Def initeIntegrationService" call="monetDef Int"/> 
</services> 

< implementation language = "maple "> 

monetDef Int : =proc(function,var .lower _limit , upper _limit) ; 
int (function, var=lower_limit . ,upper_limit) ; 

end: 

< / implement at i on> 

< implementation language = " derive "> 

monetDef Int (f ,x, a, b.e) := PR0G( e : =INT(f ,x, a,b) , return(e)) 

< / implement at i on> 

<implementation language = "mathematica"> 

monetDefInt [f_,x_,a_,b_] := Integrate [f , {x, a, b}] 

</implementation> 

< implementation language=" axiom" > 

) clear completely 
monetDefInt (f ,x,a,b)== 
integrate (f ,x=a. .b) 

< / implement at i on> 

</mathServer > 

6.2 Changes to the Mathematical Server Components 

In order to enable capabilities of Mathematical Server to handle services us- 
ing various mathematical engines, the developer of a particular instance of the 
mathematical server has to replace the elements of the Invocation Manager that 
depend on the mathematical engine. These are the code generation, the tools for 
conversion between OpenMath and the language of this system and an adapter 
that allows to plug the system software into Mathematical Server environment. 

Essentially, this means providing new code for Java classes implementing 
these functions. The good news is that the stubs of these classes, once created, 
can be reused by simply pointing to the location of their files during Mathe- 
matical Server installation. Currently we have created such code stubs for two 
computer algebra systems: Maple and Axiom. None of this is completely straight- 
forward, but fortunately these tasks need be done only once for each system. 

The whole structure of Mathematical Server, as well as its tools assigned to 
install and maintain new services remain the same, since they do not depend on 
the mathematical engine. 

6.3 Current Status and Future Work 

We have successfully applied this technique to switch between two computer 
algebra systems. Maple and Axiom. We have not yet experimented with substi- 
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tuting the mathematical engine with a Fortran program using NAG libraries, 
but we believe that the organization of the web server and mathematical web 
services will easily allow this. 

7 Conclusion 

We have described an approach to providing mathematical web services in which 
authors wishing to provide services need know only the mathematical software 
packages with which they are already familiar. No knowledge is required of Java, 
WSDL or other web technologies. We see this as a significant benefit over pre- 
vious approaches, given the rarity of individuals with expertise in both web 
technologies and mathematical software. 

For each mathmatical software system used to implement services, a trans- 
lator program to and from OpenMath must be provided. This is required only 
once for each system, however. 

The client-side interface to the mathematical services is suitable for use both 
by software systems and end users. It is currently used to serve a test web site pro- 
viding a selection of symbolic mathematical services at http : //ptibonum . scl . 
csd.uwo . ca: 16661/MonetServiceClient . It is also used for on-going experi- 
mentation with complex service brokers that plan solution strategies combining 
services from different mathematical software systems. 
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Abstract. We introduce a fundamental concept found in the formal se- 
mantics of language, categorial type logics, into the field of knowledge 
communication language design in general, and into mathematical con- 
tent markup language design in particular. 

Categorial type logics permit the specification of type systems for 
knowledge communication languages that are both complete wrt. lan- 
guage structure and extensible wrt. the lexical component. 

We apply this concept to OpenMath, and propose a categorial type 
logic for that language which matches well with its intended semantics. 
The proposed type logic is a simpler version of the well-established L2 
categorial type logic, from which it inherits decidability and other useful 
mathematical properties. 

As a practical result, we report a serious problem in the OpenMath 
1.0 specification. 



1 Introduction 

We have long argued [12] that content markup languages need to obey the Com- 
positionality Principle which requires that “the meaning of a compound expres- 
sion is a function of the meaning of its parts and of the syntactic rule by which 
they are combined.” [11] Many languages for communicating or processing math- 
ematics have non-compositional features [12] that frequently turn out to be bugs 
[16, 14], but the core of OpenMath [1,4] does comply with this principle [16]. 

Mathematically, the compositionality principle has been modeled in the lit- 
erature as a requirement for the existence of an interpretation that acts as a 
homomorphism from a syntactic algebra to a semantic algebra. From a more 
practical computer scientist’s perspective we have noted that it implies that 

“a language for expressing semantics for exchange among computer pro- 
grams [...] define[s] a basic interpretation procedure - how to inter- 
pret the parts, and how to interpret the combinations of parts. [...] 
[C]ompositionality means that one is able to provide a firmly grounded 
scaffolding from which one can work to extend the scope of [the] language 
by adding only lexical entries, while keeping the scaffolding intact.” [12] 

The challenge for the practical designer of languages like OpenMath is to 
provide such a basic interpretation that can act as a semantic scaffolding for their 
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language. This exercise can be a valuable design tool for content communication 
languages, as we will show here by applying it to OpenMath. 

A skeleton semantics for a compositional language, as we termed it [12], i.e. 
a compositional semantics that respects the syntactic structure of a language, 
has been studied in formal linguistics under the general heading of “categorial 
grammar,” and it is in this sense that we use the term “categorial” here. 

The interested reader is invited to consult M. Moortgat’s survey of Categorial 
Type Logics [13] for a justification and history of this terminology, and for an 
in-depth treatment of both the notions and the notations we use in the following. 



2 Problems of a Formal Semantics for Content Markup 

The specification of a semantics for content markup languages like MathML- 
Content [6] or OpenMath is a thorny issue. Both languages have side-stepped the 
issue by declaring their semantics “informal” and thus, open to interpretation. 

In the case of OpenMath, however, two proposals for OpenMath type systems 
were published simultaneously with Version 1.0 of the Standard [4], in order to 
provide a more (“Strong” OpenMath [5]) or less (Small Type System [7]) detailed 
semantics for OpenMath objects. The idea is that many type theories exist, all 
of them equally valid, and since any formal semantics induces a type theory, any 
number of such semantics for OpenMath must be allowed to co-exist. 

No such publication seems to exist for MathML Content markup, perhaps 
because the MathML philosophy specifically declares its semantics informal. 

On the other hand, developers of another knowledge communication lan- 
guage, the Knowledge Interchange Format (KIF) [9], provide a fully formal se- 
mantics (although not a type theory) for their language. Ontologies based on KIF 
have included “engineering mathematics” [10], making KIF directly comparable 
with MathML and OpenMath despite its quite different designated application 
area of intelligent agent communication. 

The main reason for avoiding the specification of a formal semantics for a 
content markup language, for example in the form of a formal type system, 
appears to be grounded in two conflicting demands on such a language and its 
semantics. On the one hand, a content markup language needs to be extensible 
in order to allow the marking-up of novel concepts in the language, but on the 
other hand a formal semantics for a knowledge communication language needs 
to be complete in the sense of providing an interpretation for all possible legal 
sentences in that language. 

Another problem is that different type theories make different choices when 
it comes to weighing type inference power (and thus the set of constructs that 
are interpreted correctly) against automatic validation speeds (or indeed decid- 
ability). Defining too weak a formal type theory, it can be argued, would risk 
prohibition of even quite common scientific formalisms, but would allow one to 
require “conforming” applications to implement it. A powerful formal type the- 
ory, on the other hand, may be able to specify the semantics for a wide range 
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of such formalisms, but its proof theory might be prohibitively expensive to 
implement or run, or even undecidable. 

The concept of a categorial semantics in general, and of a categorial type 
system in particular, tries to provide a good compromise between the extremes 
of both these dimensions. 

On the one hand, a categorial semantics is complete with respect to the 
syntactic structures provided by a content markup language, but it is at the 
same time extensible with respect to the lexical ingredients of the language. By 
providing a clean conceptual interface to “external” type theories on atoms of 
the language, it acknowledges that different formal semantics are possible and, 
indeed, useful, but by providing a single common structural semantics for the 
language it makes sure that any two such semantics agree at least on the basic 
meanings of an expression. 

On the other hand, a categorial semantics of a content markup language 
can in principle be kept simple enough to be implemented easily, so that its 
ease of implementation or its inference power would depend on the application’s 
choice of a more or less complex “external” lexical semantics, on which choice 
the categorial semantics itself is agnostic. 



3 Origins of Categorial Semantics 

As mentioned earlier, we have “stolen” the concept of a categorial semantics from 
Formal Semantics, a.k.a. Montague Semantics, a branch of Formal Linguistics, 
where categorial types are a fundamental tool for studying the structure of the 
semantics of language, and Categorial Type Logics [13] have been studied exten- 
sively. 

We therefore adapt a formalism from this field, known as the Lambek calculus 
[13], for the purpose of illustrating its usefulness in the much more recent field 
of content markup language design. We thus follow a historical precedent in 
that a seminal paper for such a calculus [2] applied it both to natural language 
sentences and to mathematical formulas. 

A categorial semantics for a language can only exist if the language obeys the 
twin principles of Strong Compositionality and Lexicalism. The strong composi- 
tionality principle requires that the semantics of a language be a homomorphism 
between its syntactic and semantic algebras. Lexicalism, in addition, requires all 
atoms of the language to be assigned a semantics (or a type) exclusively via 
a lexicon, leaving the semantics of compound expressions of the compositional 
language to be induced via semantic constructors. 

The Lambek calculus [13] is originally one of syntactic categories only (hence 
the term categorial). However, via the homomorphism between syntactic and 
semantic algebras postulated by the strong compositionality principle, the syn- 
tactic Lambek calculus immediately translates to a semantic one. 

The semantic version of the Lambek Calculus is thus commonly understood as 
a type logic, where syntactic categories are homomorphically mapped to semantic 
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types., and it is this interpretation that we will apply to the content markup 
language OpenMath in the following. 



4 Lambek Types and the Lambda Calculus 



As a gentle introduction to the Lambek calculus, we will briefly show how it can 
be used in a type theory for the Lambda calculus. 

Lambda calculus expressions of the form fxy (i.e., applications) are assigned 
the type F • X »Y, where upper-case letters denote the type of the correspond- 
ing variables denoted in lower-case letters, and • denotes type-level application. 
Lambda abstraction expressions of the form (Xx.f), on the other hand, are as- 
signed the type X\F in this calculus. 

Given this definition, the Lambda calculus expression {{\x.{\y.fxy))x)y has 
the Lambek type {{X\(Y\{F • X • Y))) • X) • Y, for example. 

The Lambek calculus then has type-level equivalents of Lambda Calculus 
reduction rules. /3-Reduction, for example, which says that 

lAfL,, ,e„„espo„*to AT/M,,,, . (1) 

/ F 

In other words, (right) application cancels (left) abstraction just like multi- 
plication cancels division. 

Notice how the left abstraction notation X\F causes it to become visually 
separated from its canceling right application F»X. We therefore propose to use 
in the following the more intuitive though clearly equivalent right abstraction 
notation F/X instead of X\F, which produces the following categorial version 
of the Lambda Calculus /3-reduction rule: 



(F/X)»X 



(2) 



In this notation, the Lambda calculus currying rules for binary functions. 



Xx.Xy.f = Xx.(Xy.f) and fxy = {fx)y , (3) 



the associativity rules for lambda abstraction for application, correspond to the 
following categorial type-level equivalences: 

FfYfX = {FlY)jX and F • X *Y = {F • X) mY (4) 



Notice how the switch to the more intuitive right abstraction division notation 
induces a reversal of the ordering of the variables (or rather, their types) in the 
type-level equivalent formula. This is a small price to pay for an otherwise nicely 
intuitive formalism, where cancelling factors are always directly adjacent. 

This is therefore the variation on Lambek’s notation for categorial type logics 
that we propose to use in the following for content markup languages, since 
these languages, like the Lambda Calculus that they tend to be based on, are 
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essentially prefix notations that do not need to distinguish between right- and 
left-hand side arguments. Again, we follow established precedent here, since this 
is actually closer to the notation ^ used in Ajdukiewicz’s seminal paper [2, 3] 
for a non-directional categorial calculus. 



5 Categorial Type of OpenMath Objects 

We will now develop a categorial type logic for OpenMath objects as defined in 
the OpenMath Standard Version 1 [4]. Following the compositional approach, 
we will examine each structural syntactic constructor of OpenMath and give it 
a categorial interpretation. In other words, we will propose a categorial type 
constructor as homomorphic image for each syntactic category of OpenMath. 

In this context, we will use the notations used in the OpenMath Standard [4] 
to write OpenMath objects, and the notation in [13] for type assignment: if Q 
denotes an OpenMath object, we let r(l7) denote its type. More generally, we 
will let r^(l7) denote its type given an environment rj of type variable bindings. 

In OpenMath 1.0, OpenMath objects are defined as abstract data structures 
that are either basic OpenMath objects or compound OpenMath objects. Com- 
pound OpenMath objects are either OpenMath application objects, OpenMath 
binding objects, OpenMath attribution objects, or OpenMath error objects; ba- 
sic OpenMath objects are OpenMath symbols, OpenMath variables, OpenMath 
integers, OpenMath floating point numbers, OpenMath bytearrays, or Open- 
Math character strings. 

OpenMath objects may also be viewed as the result of parsing their encodings, 
i.e. as an abstract syntactic structure. It is in this interpretation that we use their 
definition as a basis for our categorial analysis in the following. 

5.1 OpenMath Application Objects 

An OpenMath applieation object has the syntax application(oo, . . . , a„) , where 
the Ui are arbitrary OpenMath objects and n > 0. 

Given its intended meaning as application, we can define the categorial type 
of an OpenMath application object as: 

T^(application(ao, . . . , a„)) := (r^(ao) • . . . • r^(a„)) (5) 

This can also be expressed as the axiom schema^ 
r^(application(ao, . . . , a„)) 

Oman (6) 

(r^(ao) • . . . • Tn(an)) 

This is essentially the same as definitions used in both the Small Type System 
[7] and Strong OpenMath [5] type system proposals for OpenMath, and it is 
rather straightforward. 



^ Note that this extends the usual Lambek notation for type-level application to the 
nullary case, by writing (r,,(ao)») for n — 0. 
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5.2 OpenMath Attribution Objects 

OpenMath attribution objects have the form attribution(ai bn,e). 

The attribute names Ui are restricted to be OpenMath symbols, whereas the 
attribute values b^ and the body e are arbitrary OpenMath objects. 

Neither of the two existing proposals for OpenMath type systems deals with 
general OpenMath attribution objects. This is understandable since semanti- 
cally, the attributions are meant to provide additional information about the 
body OpenMath object without actually “changing” its meaning. This is true 
only for OpenMath 1, however: OpenMath 2 will introduce the concept of se- 
mantic attributes that are allowed to change meanings. 

As a categorial type definition for an OpenMath attribution object with a 
single attribute we propose 

r(attribution(a b, e)) := (r(a) • t(6)) • r(e) (7) 

or, as a proof schema with the unchanged environment rj made explicit, 
T„(attribution(a &, e)) 

— ^ omattri (8) 

{Tn{a) • Tn{b)) • Tr,{e) 

The OpenMath Standard declares that the following syntactic equivalence 
holds for OpenMath attribution objects: 

attribution(ai &i ,02 b 2 ,e) = attribution(ai &i,attribution(a 2 & 2 ,e)) (9) 

from which we get the following fully general type assignment for OpenMath 
attribution objects: 

T,,(attribution(ai 6i, . . . , a„ 6„, e)) 

omattrn (10) 

{Tr,{ai) • Trj{bi)) • (. . . ((r,,(a„) • r,,(6„)) • T^(e)) . . .) 

The OpenMath 1 intention that attributions not modify the meaning of the 
attributed object is modeled in our framework by restrictions on the signatures 
of attribute name symbols - an approach that is compatible with changes in this 
policy in OpenMath 2. We discuss OpenMath lexical semantics below. 

5.3 OpenMath Binding Objects and OpenMath Variables 

An OpenMath binding object has the form binding(5, ui, . . . , e). The com- 

ponents of an OpenMath binding object are its head b, called a binder if it is 
an OpenMath symbol, its bound variables V\ . . . u„, and its body e. The binder 
and the body are both arbitrary OpenMath objects, and the bound variables 
are either OpenMath variables or OpenMath variables embedded as the body of 
an OpenMath attribution object. 

Caprotti and Cohen [5] deal with OpenMath binding objects only in the case 
of a single, explicitly typed bound variable. Their proposal can be expressed in 
our formalism roughly as 

T(binding(6, attribution(type t,v),e)) := T{b) • T{t) • (T{e)/T{t)) (11) 
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Since we are aiming to be fully general, however, we need to define a cat- 
egorial type for all OpenMath binding objects, typed or untyped and with an 
arbitrary number of bound variables. We therefore offer the following simplified 
type assignment for OpenMath binding objects:^ 

T(binding(&, Ui, . . . , u„, e)) := r(&) • (T(e)/r(n„)/ • • • /t{vi)) (12) 



This corresponds to an interpretation of an OpenMath binding object as 
forming an abstraction over the variables v\ . . .Vn with body e and applying the 
binder 6 to the resulting abstraction: binding(6, wi, . . . , t>„, e) = b{Xv\.- ■ ■ Af„.e). 

These type assignments have a nicely simple form, but they do not yet for- 
malize sufficiently the fact that variable binding modifies the environment ry of 
type assignments to variables. The following axiom schema does this properly 
in the case of OpenMath variables Vi . . .Vn' 



r^(binding(6, wi, . . . , u„, e)) 

Triib) • ■ ■ ■ /Vi) 






(13) 



This still ignores OpenMath binding objects in which the bound variable 
OpenMath objects are not simple OpenMath variables but attributed OpenMath 
variables. In the case of a single bound variable with a single attribution, we get, 
by combining (7) and (12): 



r,,(binding(&, attribution(ai bi,v), e)) 

Tr,{b) • {T[v:V\r,]ie)/{{Tr,{ai)»Tr,{bi)) • V")) 



(14) 



Since generalizing this formula to arbitrary numbers of variables and attribu- 
tions per variable yields a rather unwieldy formula, we will leave it as an exercise 
to the reader. 

For OpenMath variables, the categorial type is generally X - a, type variable: 



omvx 

X 



(15) 



where rjx-.x stands for the type assignment X for the variable x in the en- 
vironment ry, i.e. the environment ry contains, for each type variable name, a 
type assignment that is itself a variable, namely, a type variable. Any concrete 
type assignment for a variable in an OpenMath object needs to be deduced via 
type inference mechanisms and unification of type variables. 

Care needs to be taken therefore that several occurrences of a variable in 
the same scope are properly assigned the same type variable as their lexical 
meaning assignment, and that the same variable name in different scopes is 



^ Note that we have lost the type information that was present in Caprotti and 
Cohen’s proposal; by providing a general type semantic for OpenMath attribution 
objects and by giving appropriate signatures to type symbols we can easily recover 
this information in our framework. 
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assigned different type-level variables in the type assignment. That is the task 
of the environment parameter rj of the type assignment r^(l7). 

Letting r]x-x stand for the type assignment {x : X) G rj such that if the 
list rj contains the type assignments {x : Xi), {x : X 2 ), ... in this order, then 
X = Xi (i.e. letting the environment 77 act as a stack of type assignments for 
variables in the standard fashion), we can now see that the above definition for 
type assignments for variables, bindings, and attributions combine to give the 
expected results: 



T[](binding(a, v, application(/, v,v))) 
'T[](a) • (application(/, v, v)) / Tyy.,v]{v)) 

T[](a) • (T[^,y] (application(/, v, v))/V) 
'r[](g) » {{r[v.v]{f) • T[y.,v]{v) • Tiy,v]{v))/V) 

r(a)[] • {{T[y,v]{f) • • V)/V) 



omby:v 



omvy 



oma2 



■ omvy 



but 



T[] (binding(a, v, application)/, v, binding(b, v, v))) 

Tl(“) • (application)/, 7 ;, binding)^, v, •y)))/r[„.y] )t;)) 

T[])a) • )r[„;y])application)/, v, binding)^, v, v)))/V) 

T (a) • )/) • T[y:v] {v) • T[y,v] )binding)6, v, v)))/V) 

T\] (a) • {(j\v.v] )/) • L • T[„y] )binding)6, v, v)))jV) 

T[](a) • ))r[„y])/) • L • {T[y,v]{b) • )r[„yi,„:y])7;)/T[„yi,„y])«;))))/L 
T](a) • {{T[v:V]{f) • V" • (r[„:V](5) • (Vl/Vl)))/V) 



omh„,v 

omVy 

oma2 

— omVy 

- omby:Vi 
omVy 



5.4 OpenMath Error Objects 



OpenMath error objects, semantically speaking, only carry the meaning that an 
error occurred. For the sake of completeness, we therefore simply note that, in 
a type inference chain, their occurrence would therefore simply trigger a “fail” 
condition, or _L: 



r^(error). . .)) 

omerr 



(16) 



5.5 OpenMath Symbols 

As in [13], “in accordance with the categorial tenet of radical lexicalism, we 
assume that the grammar for [our language] C [= OpenMath] is given by the 
conjunction of [its] general type logic with [its] language-specific lexicon lex(£) 
[which is] characterized in terms of a type assignment function” that assigns a 
set of applicable categorial types to a lexical item. The type assigned to a lexical 
item therefore does not need to be unique, as one of the earlier type systems for 
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OpenMath stipulated, but it is assumed that there are only a finite number of 
distinct alternatives. [13] 

In the case of OpenMath symbols, OpenMath realizes lex in the form of 
OpenMath content dictionaries and zero or more associated “signature” decla- 
rations. Signature declarations depend on the type system they are embedded 
in. At least two such systems have already been defined for OpenMath, but none 
cover all existing OpenMath content dictionaries. 

We discuss common patterns of categorial signatures of OpenMath symbols 
below. 



5.6 Other Basic OpenMath Objects 

In addition to OpenMath variables, OpenMath distinguishes several different 
kinds of constant leaf objects, or basic OpenMath objects. Since they are syntac- 
tically distinguished, we need to discuss categorial type assignments for each. 

In the interest of a “pure” categorial semantics, we could assign all constant 
basic OpenMath objects the type X - i.e., unknown, variable. However, Open- 
Math integers are one example where the intent is quite clearly that they be 
representations of integers, and their type thus Z. 

Both strategies are sanctioned for a categorial OpenMath grammar that we 
quoted above, so that we will not propose a specific choice here. 



6 Categorial Type Inference Rules and OpenMath 

Now that we have defined the basic translations for OpenMath object structures 
into categorial types, we need to choose which categorial type inference rules 
should apply to them in order to complete the categorial type logic. 

6.1 /3-Reduction 

A type-level version of /3-reduction applies to OpenMath types to capture the 
intended meanings of OpenMath application objects and OpenMath binding 
objects. The categorial /3-reduction inference rule schema for OpenMath is: 

(d/33i • • • /Bn) • Bn ■■■•Bi 

om/3„ UO 

A 

This simply means that applying an n-ary function object with argument 
types Bi . . . Bn to n arguments of the correct type in the correct order results 
in an element of the result type of the function object. 

Note that in linguistic applications, we only find a single inference rule of 
this type for n = 1. This is because in the Lambda calculus (which is used in 
linguistic applications) both application and abstraction obey an associativity 
law. OpenMath as such does not obey these laws (see below), so that we have 
to use a rule schema for the type-level version of /3-reduction for all n > 0. 
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6.2 Currying 

OpenMath 1.0 provided very limited support for another type inference rule that 
is usually found in such contexts, namely the currying rules: 

(A/B/C) A»B*C 

/assoc* and •assoc* . (18) 

{{AIB)/C)' {A,B),C 

Neither of these rules, however, is defined for OpenMath objects in full gen- 
erality. The only currying rule that the OpenMath 1.0 Standard clearly specified 
holds for OpenMath binding objects and corresponds to the type inference rule 

D.{A/B/C) 

om assoc . (19) 

D.{{D.{AIB))/C) 

This rule is modeled on the abstraction currying rule /assoc* above which 
we could attempt to recover from the OpenMath binding object currying rule 
ora/ assoc by letting D = {X/X) and applying the /3-reduction rule om(3? 

Unlike for OpenMath binding objects, no currying rule is defined for Open- 
Math application objects in the OpenMath 1.0 Standard - the usual symmetry 
between application and abstraction currying is broken. Since the currying rules 
are actually derived from the observation that 

{x,y^ f){a,b) = {{x {y f)){a)){b) , (20) 

a rule that applies only if both application and abstraction are curried, we have 
reason to be worried. 

We thus perceive a mismatch between the categorial type system that we 
propose on the one hand, and the definitions of the OpenMath Standard 1.0 on 
the other. This may be due to problems in the categorial semantics approach we 
advocate, or it may be due to problems in the OpenMath definition - we show 
here that the OpenMath 1.0 definition was in error. Indeed, we will show that it 
is impossible to define a correct syntactic rule for currying OpenMath objects. 

The reason is that the particular way that OpenMath binding objects are 
structured is asymmetric with respect to the way that OpenMath application 
objects are structured, and this asymmetry dooms any attempt to introduce a 



3 



{X/X) • {A/B/O 
A/B/C 



oml3i,X = A/B/C 



and 



(X/X) . (({Y/Y) . {A/B))/C) 

{X/X) • {/A/B)/0 

omfdi , X — 

{A/B)/C 



om(3i, Y = A/ B 
{A/B)/C 



Note that we have to cheat a bit by giving each copy of U a different copy of its 
signature {X/X vs. Y/Y) in the second derivation in order to achieve this result. 
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general-purpose currying rule for OpenMath application objects and OpenMath 
binding objects. 

To see this we consider again the type-level version of the OpenMath binding 
object currying rule (19): 



D,{AIBIC) 

om assoc 

D.{{D.{A/B))/C) 



( 21 ) 



Notice that the {D • (A/B)) in the second line of this rule, that is the type 
of the values returned by elements of B> when applied to elements of {A/B), 
must match the A of the first line, that is the type of the body of the OpenMath 
binding object: an OpenMath binding object needs to return the same result 
type as its body returns in order for this currying rule to even make sense. 

Quantifiers have predicates as bodies, which return truth-values, and they 
themselves also return truth- values. Similarly, operators that are induced by n- 
ary associative functions (e.g. X) induced by -I-, or the “big” version p| of n) 
all return the same type of value as their bodies do. With the currying rule an 
axiom of Lambda calculus, all the binder symbols defined in early OpenMath 
versions in fact obeyed this currying rule! 

Not all binders fit this model, however, just as not all n-ary functions are 
associative. Here are a few well-known counter-examples: 

the : as in lx.P{x): “The unique x such that P{x) is true”. The body P 

returns a truth value, while the generalized quantifier t. returns an object 
from some arbitrary domain. 

some : e as in ex.P{x): Chooses “some x that satisfies P(a;)”. 
sequence : (Hj)jg]N - the sequence of all Ai where i ranges over the natural 
numbers, for example. The body returns elements of the sequence, but the 
binder returns a sequence of such elements. 
set of : {x I P{x)} - the set of all x that satisfy P{x). 



The first two in this list were not defined in early versions of the OpenMath 
content dictionaries, and the final one was defined as a multi-argument operator 
rather than a binder, so that this problem was not immediately apparent. 

However, the class of counter-examples is clearly open-ended, as it includes at 
least one element per non-associative n-ary operator in mathematics. It clearly 
contains important concepts that OpenMath will need to represent. Hence, the 
class of counter-examples is anything but negligible. 

The currying rule for OpenMath binding objects is therefore irreparably bro- 
ken. Based on the results reported here, OpenMath version 1.1 has therefore 
removed the currying rule completely to fix this major bug in OpenMath 1.0. 



7 On a Lexical Semantics of OpenMath 

Recall that “the grammar for [OpenMath] is given by the conjunction of [its] 
general type logic with [its] language-specific lexicon” LEx(OpenMath) which 
assigns categorial types to lexical items. 
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The detailed lexical semantics of the full set of OpenMath symbols, i.e. the 
full definition of LEx(OpenMath), is explicitly not within the scope of this paper 
- the whole point of a categorial semantics is the ability to factor out that aspect 
of meaning. It is, however, of interest here to study what kinds of signatures 
an OpenMath categorial type logic might have to support, i.e. what entries in 
LEx(OpenMath) might look like, and if the mechanisms we have introduced so 
far are up to the task of handling them. Space constraints only allow us to cover 
the most important aspects of this question here, however. Additional details are 
discussed in [15], and a full treatment will be the subject of a later publication. 

Regular constants, functions, or relations typically can be assigned signatures 
such as r(pi^^^,) := IR or G {(IR/IR), (C/C)}; as type inference rules: 



^(pi ) 

IR 



LEX 



r(sin„„„i) 

C/C 



LEX 



IR/IR 



LEX 



(22) 



Note that we use concrete mathematical type constants such as IR for the 
reals and C for the complex numbers in these examples instead of the type 
variables that we have used in our examples so far. This is in keeping with the 
OpenMath philosophy that signatures of OpenMath Symbols are given modulo 
a concrete type system. 

Here is a simple example of how the categorial and a concrete lexical type 
system might interact profitably to infer the type IR of sinyr: 



r(application(sin„„,,,,pi„„^J) 



(^(siiit,, 



'^(pi.^si)) 



oma 



((IR/IR) .IR) 
IR 



LEX 



/3 



Binder symbols have slightly more complex signatures, as they include type 
variables: T(the,„„t 42 ) := T/(T/A). An attribute name has a signature which 
ignores the attribute and returns the type of the attributed object unchanged: 
r(mathinlp„„„„ti„) := (A/A)/MmlPresType. 

Our examples use concrete types “plugged” into the categorial type system we 
propose from a concrete type system chosen purely for illustration purposes. This 
illustrates the usefulness, but also the limitations of the concept of a categorial 
type system: it mirrors very well the partitioning of the OpenMath language 
into the fixed definition of the structure of OpenMath objects on the one hand 
and the open and extensible set of OpenMath symbol definitions in OpenMath 
content dictionaries on the other, defining the former, “plugging in” the latter. 

The important difference between this approach and previous type system 
proposals for OpenMath is that in our example above the signatures of symbols 
do not consist solely of constructors and constants of a separate type theory, but 
utilize standardized categorial type constructors for application and abstraction 
in conjunction with constants from a sample concrete type theory. 

Simple and elegant though this idea may sound in theory, it immediately 
brings up the practical question of how a categorial type theory like the one we 
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propose, on the one hand, and a concrete “plug-in” lexical type theory, on the 
other, would interact mathematically and proof-theoretically. 

To see that this question is not quite trivial, consider the deceptively simple 
example formula (sinTr = 0) expressed in OpenMath. A few predicates such 
as equality are polymorphic, applicable to elements of any type at all. We can 
express this easily in the categorial framework by using type variables instead 
of constant type names in the signature: :=lex ‘IjXjX. With this 

definition in place, we can now deduce that (sinTr = 0) stands for a truth value: 



"(application(eq_.^j^^,^_^^j, application(siiiir, 






,J,0)) 



^(eq„latio„sl) • (r(sin„„„i) • T(pi^^^J) • t(0) 



{2! XIX) • ((M/IR) • IR) • ^ 



LEX 



(2/AI/A:) •IR«^ 



/3i 



(2/W/W) •]R«]R 



^ C IR 



HX = M) 



This derivation uses two important new details. First, as a new aspect of 
the categorial type logic, it uses unification to deduce a possible value for the 
type variable X from the structure of the /3-reduction rule in the (32{X = M) 
inference step. Second, it includes a derivation step that is true only in the 
plugged-in concrete lexical type theory {7Z C M), in this case, a deduction 
based on a simple type hierarchy. 

Together, these make the question of an interaction between a categorial type 
logic and a “plug-in” lexical type theory quite non-trivial. Luckily, this question 
has been studied in a general form in the categorial semantics research area of 
formal linguistics, from where we “stole” the idea in the first place - another good 
reason to explore a linguistics parallel for a general theory of content markup 
languages. In [13] we find that the categorial type logic that we propose for 
OpenMath is a simpler version of the L2 type logic, the positive features of 
which it thus inherits. In addition, [8] “explores the consequences of layering a 
Lambek calculus over an arbitrary constraint logic,” and “[provides] for [such a] 
hybrid language a simple model-theoretic semantics, [where] the proof system 
for the underlying base logic” (in our context, the type logic for a concrete “plug- 
in” type system) “can be assumed to be a black box that performs entailment 
checking'' (such as subtype checking for the plugin type system). 



8 Summary and Outlook 

In this paper we have introduced the formal linguistics concept of a categorial 
type logic as surveyed in [13] into the field of content markup language design. 

The concept of a categorial type logic, especially in the form of a Lambek 
calculus that we adapted here to our use, applies to a language that obeys 
the compositionality principle. In [16] we argued that OpenMath [4, 1] is the 
first knowledge communication language to meet this requirement; it is thus 
OpenMath that we apply this new concept to in this paper, with some success. 
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— We have proposed a basic categorial type logic for OpenMath 1.1 that 
matches well with the intended semantics of core OpenMath. 

~ The basic categorial type logic is a simpler version of the well-known and 
extensively studied restricted second-order polymorphic L2 categorial type 
logic [13] (without associativity, i.e. currying), and it inherits decidability 
and other useful mathematical properties from it. 

~ The interaction between a categorial type logic of this kind, and a very gen- 
eral class of “plug-in” lexical type theories, has been studied in the linguistics 
literature, and we get decidability of the combined (or rather, layered) type 
logic given decidability of the plug-in lexical type theory [8]. 

— Categorial type logics thus allow us to specify a complete categorial seman- 
tics for OpenMath, which fully supports extensibility both with respect to 
its “lexicon” (i.e. OpenMath content dictionarys) and with respect to the 
support for multiple competing lexical type theories. Previous type system 
proposals for OpenMath have been incomplete in that the type semantics of 
some core OpenMath constructions were not fully specified. 

— Problems with the OpenMath 1.0 Standard [4] that we discovered using this 
tool, are, on our suggestion, fixed as of OpenMath 1.1. 

A price that we have had to pay for this success in the case of OpenMath 
is that the resulting categorial type logic is non-associative, which would cor- 
respond to a loss of currying in an underlying Lambda calculus. However, as 
we have seen, this price is a direct consequence of a specific design decision for 
OpenMath that we have thus been able to show would need to be seriously re- 
considered in future versions of OpenMath, namely, the decision to represent 
OpenMath binding objects with a header element instead of using the Lambda 
calculus as a basis for OpenMath. 

As a design guideline for future versions of OpenMath in particular, and 
for all content markup and knowledge communication languages in general, we 
therefore suggest aiming for a design that supports a categorial type logic L2 
with full support for currying and with those restrictions on second-order quan- 
tification that make it decidable [13]. This suggestion has profound consequences 
for the range of admissible syntactic structures of such languages. 

It remains to study in more depths the consequences of these ideas for lexical 
type systems for OpenMath, since we were only able to scratch the surface of this 
topic here. MathML would also benefit from a definition of a categorial seman- 
tics for its content markup language, as would other knowledge communication 
languages. 

In summary, the concept of a categorial grammar, and the compositionality 
principle it derives from, have been shown to be a powerful design tool (or design 
principle, resp.) for content markup languages. 
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